.NET Core 2.1, 3.1, and .NET 5.0 updates are coming to Microsoft Update

Jamshed Damkewala

Jamshed

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.

 

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.

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).

MU opt-in

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.

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.

Updates available

 

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.

WSUS - Select Products and Classifications

.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.

WSUS Create Rule

 

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:

  1. Un-approve the products you previously approved in the WSUS admin console.
  2. 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 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 5.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\5.0] "BlockMU"=dword:00000001

Alternatively, you can use Group Policy to deploy the registry key to many computers at once.

GPO - Block MU

 

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.

 

 

 

 

 

 

 

 

 

39 comments

Comments are closed. Login to edit/delete your existing comments

  • Avatar
    Ralph

    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)

    • Jamshed Damkewala
      Jamshed DamkewalaMicrosoft employee

      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.

  • Avatar
    Max Mustermueller
    1. 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?

    2. 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.

    • Jamshed Damkewala
      Jamshed DamkewalaMicrosoft employee

      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.

    • Avatar
      Marius Kanaporis

      .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….

  • Avatar
    Irakli Lomidze

    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)

  • Avatar
    宜史 西家

    Please, Distribute the latest supported Visual C++ redistributable packages on Microsoft Update, too.

  • Avatar
    Philip Mattson

    Awesome! It was becoming a little tedious to both apply Windows Updates and then consider what .Net Core/5 updates were required.

  • Avatar
    Reilly Wood

    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… 🤯

  • Avatar
    Violet

    Hi,
    will .NET frameworks be decoupled from the Windows 10 in a future build?