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.
Background
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.
The Details
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.
Runtime Roll-Forward
.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.
Reboots
.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
Automatic Updates
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.
Synchronizing Updates
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.
Approving Updates
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.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NET\6.0]"BlockMU"=dword:00000001
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 |
In Closing
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.
Can you clarify the impact to .NET Core when a “Security Update” is applied? Will developers need to update their applications when security updates are installed, as they might when .NET Core itself updates?
Is this live for WSUS yet?
The .Net Core products don’t exist as products to enable on my WSUS server (2016). Is there any particular update, hotfix, or registry tweak needed to enable these new products to appear in the catalog?
I’m wondering the same thing. I see .net 5.0 listed but I don’t see .net core 2.1 or .net core 3.1 in WSUS under Developer Tools, Runtimes and Redistributables. Could you please provide some clarity? Thanks very much.
Same here. Only .Net 5.0 is listed. Cannot find any info if that is expected or there is something that needs to be done to see the others as well.
In December we had no updates for 2.1 or 3.1 to ship (via MU or otherwise), we only had an update for 5.0 (5.0.1). For Jan (next week) we will be updating all 3 supported versions and all of them will be delivered via MU.
Microsoft Update did not update .NET SDK 5.0.100 to .NET SDK 5.0.101 on Windows Server 2012 R2, which is on extended support until 10/10/2023. .NET SDK 5.0.101 does not show up as an optional update, either. Is the feature expected to work on Windows Server 2012 R2? If not, which version of Windows does it require?
If you are using WSUS or SCCM you should see updates for Server 2012 R2, Server 2016 and Server 2019. Updates are not automatically pushed to Servers that are unmanaged because most customers don’t want that.
Is there a Registry value that can be set to opt in to these updates on unmanaged Windows Server?
Unfortunately, no – server SKUs will get updates only if they’re managed by WSUS or SCCM.
+1 for this feature. At a minimum can we have a registry key to opt in to updates on Server SKU’s when not connected to WSUS or SCCM. Like others we have been waiting ages for this feature, and to have it disabled at the last hurdle is a disappointment to say the least!
Thanks for the feedback folks. We're continuing to gather customer feedback on .NET Core releases shipping on MU (we have 2 monthly updates under our belt so far). Once we're past the initial phase we will look at top customer asks to help inform for future direction/enhancements in this space. If pushing updates via Automatic Updates to Server SKUs shows up as a feature in high demand by many customers we will certainly factor that...
That is really a shame. In our environment, we use neither WSUS nor SCCM for patching servers; rather, we use a combination of PowerShell scripts (which call the Windows Update Agent API) and the Azure Automation Update Management solution. We would very much like to have these updates offered to our servers.
Please consider adding an opt-in switch for servers.
This is a disaster! We have been waiting ages for this specifically for automatic deployment via MU to unmanaged servers. Please please reconsider this. At least give the option to opt-in un managed servers. We have many many unmanaged servers that patch via MU and currently is a huge amount of work to manually patch all the .NET cores.
We never had an issue on client OS as these were all managed perfect via Visual...
I added a clarification around this in the main post.
May I assume that these updates will only apply to installed instances of .NET Core?
We use an x-copy model of app + runtime for deployments. (Hence, no installers.)
Correct, that is what we mean when we refer to the “Framework Dependent Deployment” model for apps. Any apps that are built as self-contained and xcopy-deploy the runtime with their app will not be affected by this.
.Net runtime is best to force users to update to encourage developers to discard old code, otherwise even if you launch .Net 10, Developers will still be forced to use .Net Framework 4
“Note: updates for the Hosting Bundle won’t be available on MU initially…”
“The .NET Core Runtime and ASP.NET Core Runtime installers within the hosting bundle will be updatable from MU.”
Can you clarify does the latter apply initially (i.e. the runtime will be updateable from MU on web servers) or is it waiting for further work with the hosting bundle?
Yes, the runtime bundles will install where applicable, they’re not blocked on the availability of the hosting bundle.
Have you fixed the problem of .Net updates that are called “Preview”, that are being delivered to Windows 10 regular users (like me), that are not part of a domain?
Updates in Windows 8.1 and below was nice in that we could clearly see a separation between normal and optional updates, but with Win 10, .Net “Preview” updates get installed automatically.
I believe you are referring to preview updates for the .NET Framework rather than .NET Core. The relevant folks are aware of this problem and investigating solutions.
Hi,
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.
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… 🤯
Great news