We are currently making an unexpected change to the way that .NET installers and archives are distributed. This change may affect you and may require changes in your development, CI, and/or production infrastructure. We expect that most users will not be directly affected, however, it is critical that you validate if you are affected and to watch for downtime or other kinds of breakage.
The most up-to-date status is being maintained at dotnet/core #9671. Please look to that issue to stay current.
If you are having an outage that you believe is caused by these changes, please comment on the reference GitHub issue and/or email us at dotnet@microsoft.com.
Affected domains
We maintain multiple Content Delivery Network (CDN) instances for delivering .NET builds. Some end inazureedge.net
. These domains are hosted by edg.io, which will soon cease operations due to bankruptcy. We are required to migrate to a new CDN and will be using new domains going forward.
It is possible that azureedge.net
domains will have downtime in the near-term. We expect that these domains will be permanently retired in the first few months of 2025.
Note
No other party will ever have access to use these domains.Affected domains:
dotnetcli.azureedge.net
dotnetbuilds.azureedge.net
Unaffected domains:
dotnet.microsoft.com
download.visualstudio.microsoft.com
Our response
We made several changes in response. We have tried to reduce what you need to do to react. In many cases, you won’t need to do anything special.
New CDNs:
- Official builds:
builds.dotnet.microsoft.com
- CI builds:
ci.dot.net
Updated .NET install script:
- The install script now uses the new domains, per dotnet/install-scripts #555
- This script has been deployed to the official locations, as described in dotnet-install scripts reference
Addressing CI installers:
- GitHub Actions has been updated to use the new domains, per actions/setup-dotnet #570
- We expect that GitHub Enterprise Server will be addressed in January.
- Azure DevOps
UseDotnetTask
will be updated in January - We do not yet have a date for updating Azure DevOps Server.
Domain configuration
We are in the process of changing the configuration of our domains. At present, they may be using a combination of Akamai, Azure Front Door, and edgio. Our highest priority has been maintaining domain operation while we initiate new service with other CDN providers and validate their capability in our environment.
We are using Azure Traffic Manager to split traffic between them, primarily for reliability.
Call to action
There are several actions you can take to determine if you have any exposure to azureedge.net
retirement.
Search your source code, install scripts, Dockerfiles and other files for instances of azureedge.net
. We also noticed that there is a lot of use of our storage account: dotnetcli.blob.core.windows.net
. Please also search for it. The storage account is unaffected, however, it would be much better for everyone if you used our new CDN. It will deliver better peformance.
- Update
dotnetcli.azureedge.net
tobuilds.dotnet.microsoft.com
- Update
dotnetcli.blob.core.windows.net
tobuilds.dotnet.microsoft.com
Note
The new CDN is path-compatible with those servers. It’s only the domain that needs to change.Please check for copies of the install script that you may have within your infrastructure. You will need to update it.
You will need to move to the latest version of the GitHub Action and Azure DevOps Task installers to ensure that you are protected from downtime.
Please check firewall rules that might prevent you from accessing our new CDNs, similar to this conversation.
Closing
We are sorry that we are making changes that affect running infrastructure and asking you to react to them during a holiday period. As you can see, the need for these changes was unexpected and we are trying to make the best choices under a very compressed schedule.
We are hoping that the mitigations that we put into place will result in most users being unaffected by this situation.
With every crisis, there are opportunities for learning. We realized that we are missing public documentation on how to best use all of the installation-related resources we provide, to balance reliability, security, performance, and productivity. We will be working on producing this documentation in the new year.