Document network requirements and proxy configuration - #54132
Conversation
Added network and firewall requirements for .NET installation, including necessary domains and ports. Included instructions for configuring a proxy and installing without internet access.
| ## Remove .NET | ||
|
|
||
| To uninstall a specific version of .NET, use one of the following methods. | ||
|
|
||
| ### Use the .NET Uninstall Tool | ||
|
|
||
| The [.NET Uninstall Tool](https://learn.microsoft.com/dotnet/core/additional-tools/uninstall-tool) is the recommended way to remove .NET SDKs and runtimes. The tool lists all installed versions and removes them safely. | ||
|
|
||
| 01. Download and install the .NET Uninstall Tool from <https://aka.ms/dotnet-core-uninstall-tool>. | ||
| 01. List installed versions: | ||
|
|
||
| ```cmd | ||
| dotnet-core-uninstall list | ||
| ``` | ||
|
|
||
| 01. Use `--dry-run` to preview what would be removed without making changes, then run without it to confirm: | ||
|
|
||
| ```cmd | ||
| dotnet-core-uninstall remove --sdk 9.0.306 --dry-run | ||
| dotnet-core-uninstall remove --sdk 9.0.306 | ||
| ``` | ||
|
|
||
| ### Use WinGet | ||
|
|
||
| To uninstall a version installed with WinGet: | ||
|
|
||
| ```cmd | ||
| winget uninstall Microsoft.DotNet.SDK.9 | ||
| ``` | ||
|
|
||
| ### Use the .NET Installer | ||
|
|
||
| To uninstall using the original installer executable: | ||
|
|
||
| ```cmd | ||
| dotnet-sdk-9.0.306-win-x64.exe /uninstall /quiet /norestart | ||
| ``` | ||
|
|
||
| Alternatively, go to **Settings** > **Apps** in Windows, search for **.NET**, and select **Uninstall**. | ||
|
|
||
| ### Verify removal | ||
|
|
||
| After uninstalling, confirm the version has been removed: | ||
|
|
||
| ```cmd | ||
| dotnet --list-sdks | ||
| dotnet --list-runtimes | ||
| ``` | ||
|
|
||
| > [!NOTE] | ||
| > Visual Studio installs and manages its own copy of .NET. Removing a .NET version that Visual Studio depends on can cause Visual Studio to stop working. If Visual Studio is installed, check its requirements before removing any SDK or runtime. | ||
|
|
There was a problem hiding this comment.
This information is partially documented in remove-runtime-sdk-versions.md under the os-windows pivot, which covers some of these methods. This information should go in that file.
| ## Pin the SDK version | ||
|
|
||
| When multiple .NET SDKs are installed, the .NET CLI uses the highest installed version by default. To ensure all developers on your team — and your CI/CD pipeline — use the same SDK version, create a _global.json_ file in the root of your repository. | ||
|
|
||
| ### Create a global.json file | ||
|
|
||
| ```json | ||
| { | ||
| "sdk": { | ||
| "version": "9.0.306" | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| When you run `dotnet` commands from a directory that contains a _global.json_ file (or any of its parent directories), the specified SDK version is used instead of the highest installed version. | ||
|
|
||
| > [!IMPORTANT] | ||
| > The SDK version specified in _global.json_ must be installed on the machine. To see which SDKs are available, run `dotnet --list-sdks`. | ||
|
|
||
| ### Control version roll-forward behavior | ||
|
|
||
| Use the `rollForward` property to control what happens when the exact version isn't available: | ||
|
|
||
| ```json | ||
| { | ||
| "sdk": { | ||
| "version": "9.0.306", | ||
| "rollForward": "latestPatch" | ||
| } | ||
| } | ||
| ``` | ||
|
|
||
| | Value | Behavior | | ||
| |-------|----------| | ||
| | `patch` | Uses the specified version or the latest patch within the same minor version. | | ||
| | `latestPatch` | Uses the latest patch within the specified minor version. | | ||
| | `minor` | Uses the specified version, or the next higher minor version if not found. | | ||
| | `disable` | No roll-forward. The exact version must be installed. | | ||
|
|
||
| For the full list of values, see [global.json overview](../tools/global-json.md). |
There was a problem hiding this comment.
I'm not sure about this content either... While this is useful information, the full goal of this article is installation, not usage.
| ## Network and firewall requirements | ||
|
|
||
| Some installation methods require outbound internet access. If you're installing .NET on a machine behind a corporate firewall or proxy, ensure the following domains are accessible before you begin. | ||
|
|
||
| | Domain | Port | Used by | | ||
| |--------|------|---------| | ||
| | `winget.azureedge.net` | 443 | WinGet | | ||
| | `cdn.winget.microsoft.com` | 443 | WinGet | | ||
| | `dotnetcli.blob.core.windows.net` | 443 | PowerShell install script | | ||
| | `builds.dotnet.microsoft.com` | 443 | PowerShell install script, checksum validation | | ||
| | `dotnet.microsoft.com` | 443 | .NET Installer download page | | ||
| | `aka.ms` | 443 | Short links used in documentation | | ||
|
|
||
| > [!NOTE] | ||
| > After installation, `nuget.org` (port 443) must be accessible for package restore to work. If NuGet access is restricted in your environment, configure a local or organizational NuGet feed. For more information, see [Hosting your own NuGet feeds](https://learn.microsoft.com/nuget/hosting-packages/overview). | ||
|
|
||
| ### Configure a proxy for the PowerShell install script | ||
|
|
||
| If your environment uses an HTTPS proxy, configure it before running the `dotnet-install.ps1` script: | ||
|
|
||
| ```powershell | ||
| $env:HTTPS_PROXY = "http://proxy.contoso.com:8080" | ||
| dotnet-install.ps1 | ||
| ``` | ||
|
|
||
| ### Install without internet access | ||
|
|
||
| If the target machine has no internet access, use the [Manual install](#manual-install) method: download the binary ZIP on a connected machine, transfer it to the target machine, and extract it there. | ||
|
|
There was a problem hiding this comment.
I'm not sure about this content. While some of this information is useful, I don't know that it belongs here. Perhaps some of it should be in the main overview, or a dedicated article. Configuring a proxy is beyond the scope of this article and is subject to the environment the user is in. They should have a system-wide proxy setup if they're in a restricted environment, or they should already know how to setup a temp proxy if they're working in that environment.
Summary
This PR adds five sections to
install/windows.mdthat were identified as critical gaps in a documentation review. The article was missing content that users and enterprise developers routinely need, resulting in unnecessary support escalations and forum searches.No existing content was changed. All additions are new sections.
Internal previews