.NET Core 2.1, 3.1, and .NET 5.0 updates are coming to Microsoft Update
12/09/2020: this post was updated to clarify that Client operating systems will get .NET Core updates via Automatic Updates, while Server operating systems will get .NET Core updates via WSUS and MU Catalog.
12/14/2021: this post was updated to reflect Hosting Bundle updates are also available on Microsoft Update now.
Starting in December 2020, we will be delivering .NET Core updates on Windows via Microsoft Update. We have received many requests for this, particularly from organizations that acquire and manage all of their Microsoft-related updates via Microsoft (or Windows) Update. This change will enable organizations to manage .NET Framework and .NET Core updates in the same way. If you don’t want to use Microsoft Update to update .NET on your machines, you don’t have to, and can continue using one of the existing options.
Applications using the Framework Dependent Deployment model will benefit from .NET Core updates delivered by Microsoft update. There is no change to apps that use the Self-Contained Deployment model, these apps are still responsible for keeping the runtime updated.
When updates for the product are available on Windows Update, the job of an enterprise IT administrator tasked with ensuring security patches are installed in a timely manner is mostly fully automated.
Until now, we did not deliver .NET Core updates automatically via Microsoft Update. This was because of earlier customer feedback around potentially breaking apps. This feedback was centered around .NET Framework major/minor feature updates (for example going from 4.5 to 4.8) which installed in-place rather than side-by-side with earlier versions.
In the .NET Core case, major/minor (feature) updates always install side-by-side. Only monthly servicing updates install in-place and replace previous servicing updates. We are delivering .NET Core servicing updates monthly without issues. .NET Core servicing updates have evolved from fully side-by-side installs to patches that replace earlier versions with “runtime roll-forward”, so once an update is deployed apps can use the latest (serviced) runtime version automatically.
Updates on Microsoft Update (MU), not Windows Update (WU)
.NET Core is an independent product, unlike the .NET Framework which is a component of the Windows operating system. Windows Update is reserved for updates to the OS, while Microsoft Update is for other products like .NET Core, Visual Studio, and so on. Therefore, updates to .NET Core will always be distinct from .NET Framework and will be available on Microsoft Update (MU) and not Windows Update (WU).
What if I don’t want .NET Core updates delivered by MU?
If you’ve opted in for receiving updates via Microsoft Update but you don’t want updates for .NET Core delivered automatically by Microsoft Update, at this time you can block these updates by following the guidance in the Blocking .NET Core update delivery from Microsoft Update section later in this post.
.NET Core applications by default run on the latest servicing update. That means your .NET Core applications will run on the latest servicing version of .NET Core 3.1, for example, after it has been installed on your machine by Microsoft Update. The same is true if you are not using Microsoft Update, however, you need to install that update manually.
In-place Install for Monthly Servicing Updates
Prior to .NET Core 3.0, each update for .NET Core installed side by side with previous updates. This resulted in computers having many versions of .NET Core updates installed even though only the latest one was being used (the previous section on Runtime Roll-Forward covered this), but these computers still incurred the disk footprint due to multiple installations. Starting with .NET Core 3.0, patches for the .NET Core Runtime and SDK are installed as in-place updates. That is, installing a new patch version (for example, 3.1.10) removes previous patch versions (3.1.0 through 3.1.9). Microsoft Update will only maintain one update within each SDK feature band.
Note: major/minor (feature) updates for .NET Core always install side by side with previous versions.
What will be delivered from MU?
Updates with both security and non-security fixes for all supported versions of .NET Core (currently .NET Core 2.1, .NET Core 3.1 and .NET 5.0) will be available on MU. These updates will target the .NET Core SDK, .NET Core Runtime, ASP.NET Core Runtime, and the .NET Core Desktop Runtime installers deployed either independently or as part of another application. .NET Core runtime binaries included with an application built as a self-contained deployment will not be updated by MU.
Updates for .NET Core have always included both security and non-security fixes in a single package. No changes are being made around this model.
Note: updates for the Hosting Bundle won’t be available on MU initially while we work through a couple of issues. These updates will need to be downloaded and deployed from our download website. We will update this post once the issue is corrected and we are ready to start delivering updates for the hosting bundle via MU. The .NET Core Runtime and ASP.NET Core Runtime installers within the hosting bundle will be updatable from MU. The third component not independently serviced outside the hosting bundle – ASP.NET Core Module (ANCM) does not need frequent servicing, and we plan to enable MU updates for the hosting bundle before we need to service this.
Starting Dec 14, 2021 updates for all bundles for all supported versions of .NET Core are available on MU. This includes the hosting bundle which was not available on MU initially.
.NET Core servicing updates replace previous updates for the same major/minor version. If files being replaced are in use, the installer bundle will signal the need for a reboot to Windows by a 3010 return code. This is a request for a reboot and can be pended/deferred if needed, though in that case the older version being updated will only be removed when the computer is rebooted.
If multiple updates are being installed from Windows Update or Microsoft Update then Windows will automatically install multiple updates at once and then reboot just once.
The .NET Core hosting bundle will restart IIS services after updating the ASP.NET Core Module (ANCM) component.
Enabling .NET Core Updates
When we say updates will be delivered via MU, this is an over-simplification because we’re really referring to a couple of different things. Microsoft Update has a few distinct distribution channels and the .NET Core updates will be available on all of them. Amongst these distribution channels, Automatic Updates is relevant to end users and consumers, while Windows Server Update Services (WSUS) and the MU Catalog are relevant to IT administrators.
For consumers/end-users and computers that connect directly to Microsoft Update
This is the experience most end users are familiar with. After you opt-in, updates are typically installed automatically, at night, with no action required.
You must opt-in to get updates from Microsoft Update by enabling “Receive updates for other Microsoft products when you update Windows” (you can find this under Settings > Update & Security > Windows Update > Advanced options).
These updates will be installed via Microsoft Update to computers with a Client operating system that have a supported major/minor version such as .NET Core 2.1, 3.1 or .NET 5.0 already installed. .NET Core updates will not be offered via Automatic Updates (AU) to unsupported versions of .NET Core, including nightly builds, or to Server operating systems. Computers with Server operating systems can receive .NET Core updates if they’re managed by Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM). See the following sections for details on how to get updates in an environment managed using WSUS or SCCM.
Alternatively, you can go to your Windows Update Settings and click on Check for updates.
If updates are available, you’ll see a list of these updates and can choose to install these immediately without waiting for automatic overnight install.
For IT administrators
Windows Server Update Services (WSUS)
This distribution channel is mostly relevant to IT administrators. An IT administrator can configure computers across the enterprise to connect to an internal WSUS server instead of connecting directly to MU over the internet. This is more efficient, since the payload is downloaded just once over the internet and served locally to internal computers. It also allows finer control over which updates are deployed to which computers and when.
Configuring Products for synchronization in Windows Server Update Services (WSUS)
Products – Updates for .NET Core will be published under .NET Core 2.1, .NET Core 3.1, and .NET 5.0 products in WSUS. These products are nested under the Developer Tools, Runtimes, and Redistributables top level product.
Classifications – Updates for .NET Core will be published under one of the following classifications based on the contents/payload: Security Updates, Critical Updates, or Updates.
You need to select these products and classifications for synchronizing in your WSUS configuration the first time. For more information about this, see this article on Products to Synchronize in WSUS.
.NET Core updates for both Client and Server operating systems will be available via WSUS.
Updates need to be synchronized with either Microsoft Update or an upstream WSUS server. Synchronization can be initiated either automatically on a pre-defined schedule, or manually. For more information about this, see this article on Synchronizing Updates in WSUS.
Updates need to be approved before they’re deployed to client computers. This approval may either be manual, or rules can be configured for automatic approval for selected product and classification. For more information about this, see this article on Approving Updates.
Using System Center Config Manager/Endpoint Config Manager
System Center Config Manager (SCCM) and Endpoint Config Manager (MECM) help manage PCs and servers with more flexibility than is possible using WSUS. Similar to WSUS, you can set up synchronization and automatic approval of updates for deployment to target machines using SCCM or MECM. If you’re using one of these management tools to manage your environment, you should refer to this documentation on Software Update management for further details.
Blocking .NET Core update delivery from Microsoft Update
Most users we asked told us they want their computers to be kept up to date and secure automatically for them, but we realize some customers may not want this. If you prefer not to have your .NET Core installation automatically updated, there are a few different options.
For computers that get updates from WSUS, or SCCM (Managed Deployment Environment)
For computers in a managed environment that get their updates from a WSUS server or are using SCCM, you need to explicitly approve the Product entries for .NET Core 2.1, .NET Core 3.1, and .NET 5.0 before you start receiving updates.
If you’ve already approved these products for updates and have a need to block the automatic deployment of updates, do one of the following:
- Un-approve the products you previously approved in the WSUS admin console.
- Set one or more of these blocker registry keys to prevent the corresponding updates from being deployed.
|.NET Core Version||Registry Key||Name||Value|
|Block all .NET Core updates||[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET]||“BlockMU”||dword:00000001|
|Block .NET 6.0 updates||[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0]||“BlockMU”||dword:00000001|
|Block .NET 5.0 updates||[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\5.0]||“BlockMU”||dword:00000001|
|Block Core 3.1 updates||[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\3.1]||“BlockMU”||dword:00000001|
|Block Core 2.1 updates||[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\2.1]||“BlockMU”||dword:00000001|
Setting the registry key can be achieved by adding one or more entries (this is an example for blocking 6.0 updates) in a “.reg” file and running this.
Note: the above registry keys are not exclusive to computers in a managed environment, they can be used on any computer to block the delivery of .NET Core updates by Microsoft Update.
Alternatively, you can use Group Policy to deploy the registry key to many computers at once.
For computers that directly connect to MU for updates (Unmanaged Deployment Environment)
For end users and other computers that connect directly to Microsoft Update (don’t use WSUS or SCCM), we recommend you use Microsoft Update to keep your .NET Core installations up to date and secure automatically. In some cases, you may want to manage this yourself – for example, if you are an enterprise that doesn’t use WSUS or SCCM and instead directly connects its computers to Microsoft Update. In this case you can set the blocker registry key(s) described in the previous section.
Alternatively, you can download/save these files and run them (remember to save these with a .reg extension so they open using regedit):
|.NET Core Version|
|Block all .NET Core updates delivered by MU|
|Block .NET 5.0 updates delivered by MU|
|Block .NET Core 3.1 updates delivered by MU|
|Block .NET Core 2.1 updates delivered by MU|
We’re excited to start delivering updates for .NET Core via Microsoft Update and look forward to your feedback on this experience. If you are an IT administrator responsible for managing deployment across your enterprise, review the above section For IT administrators so, you are ready on day one.
At last – Thank you.
Thanks! This change makes it a lot easier for IT admins!
Does this affect the .NET SDKs from Visual Studio too? (“from Visual Studio” suffix)
We will update the .NET Core SDK including those installed by Visual Studio, but there’s a nuance. If a specific version of VS has a dependency on a specific .NET Core SDK and we have a newer update available then the SDK update will be offered and installed, but the older SDK will not be removed until VS itself is updated to no longer reference/have a dependency on the older SDK version.
What happens on major releases? Let’s say customer has .NET (Core) 3.1 installed. Does he automatically gets .NET 5.0 when its available or does he needs to install .NET 5.0 and only get minor updates based on installed runtimes?
The fact that this needs to be an OPT-IN, makes it useless in non-enterprise environment. The great majority of users will not take that switch in Windows Update and thus, as a developer, you still have to deal with support inquiries a lot. Considering how much the .NET team tries to convince developers witching from .NET Framework to .NET (Core) and makes .NET 5 the future, it should be built into Windows by default. Just like the new Edge. I really hope this comment gets read by someone who is responsible for this and might start a discussion. I’m sure I am not the only developer seeing this as an issue, now and in the future.
We have no current plans to make new major and minor updates available via MU. Servicing updates for 5.0 will only be offered if you install 5.0 yourself. We will not push 5.0 down to your computer if you did not already have this. Also remember new major and minor releases will always remain side by side installs with previous versions, which means if you have 5.0.1 installed and we ship a 5.1 or 6.0 then your 5.0.1 will not be replaced by 5.1 or 6.0. Even if we decide to make new major/minor updates available via MU they will not replace your the major/minor so there should be no compatibility issues due to that. Applications can choose if they want to roll forward to a new major or minor update automatically, but by default they only roll forward to a new servicing update within the same major/minor version.
There are also no plans at this time to include .NET Core as a component of Windows, it will remain an independent product.
.NET framework already was a windows component, thats why .net core was created, and has been developed so much faster. You clearly want another .net framework which stands against everything .net core is….
It sounds good.
We do not want our software to become a vector of attacks. So we need the followings:
1) We also need some service to identify updates, for our software packed with .net core. Service API from Microsoft Update.
2) Recommendation and some source code of the updater service for updating our .net core app (without rebooting application when possible)
Unfortunately there are no plans currently to build an updater service for apps that choose to use the self-contained deployment. Many customers especially those using a CI/CD flow are using our release metadata JSON to get information about .NET Core updates to deploy and rebuild their apps. Have you taken a look at this?
Will URL you provided “release metadata JSON” remain unchanged for years?
Could we rely on it for an extended time?
Nice! I’m keen on seeing the Hosting Bundle land in MU through WSUS.
Please, Distribute the latest supported Visual C++ redistributable packages on Microsoft Update, too.
this comment has been deleted.
Awesome! It was becoming a little tedious to both apply Windows Updates and then consider what .Net Core/5 updates were required.
This sounds great but I hope you can clear up the names/branding somehow. This blog post talks about how Microsoft Update is different from Windows Update, but the name “Microsoft Update” is never mentioned in the settings UI and it’s controlled via Windows Update settings… 🤯
will .NET frameworks be decoupled from the Windows 10 in a future build?
There are no plans to remove the .NET Framework 4.8 from Windows 10 releases in the future.
this comment has been deleted.