TL;DR .NET Core and .NET 5 servicing updates can now be installed automatically on Windows, through Microsoft Update.
Today I watched .NET Core and .NET 5 versions updated automatically for the first time.
Runtimes were updated
All supported runtime already installed get updated. In my case, I received the following new versions:
- Microsoft.NETCore.App 3.1.12
- Microsoft.AspNetCore.App 3.1.12
- Microsoft.WindowsDesktop.App 3.1.12
- Microsoft.NETCore.App 5.0.3
- Microsoft.AspNetCore.App 5.0.3
- Microsoft.WindowsDesktop.App 5.0.3
- Microsoft.NETCore.App 2.1.25
- Microsoft.AspNetCore.App 2.1.25
SDKs were updated
All .NET Core SDKs installed were also updated and as per manual SDK installs, the previous versions were replaced.
There is one exception to this - where Visual Studio has a dependency on a particular version and after my update I did find that I now had 2 .NET 5 SDK:
However, when I updated my VS from 16.8.3 to 16.8.5, 5.0.101 was removed.
The ASP.NET Core Module was not updated
Work has been promised to service the hosting bundle (for working with ISS) through Microsoft Update, which I don’t think is finished yet. I popped an older hosting bundle on my local machine but no offers of anything newer from Microsoft Updater so assuming it’s not ready yet.
Affect on side-by-side installs
One of the benefits of Core is the ability to have side-by-side installations of runtime versions. This is unchanged:
- Major and minor versions will co-exist with their respective applications.
- Servicing updates will not overwrite previous servicing versions.
The only thing that has changed is that the servicing update can be installed automatically through Microsoft Update instead of being a manual task.
By default, .NET Core applications will continue to only roll forward to the latest available patch version installed unless there is no available runtime for the targeted minor version.
- If 3.1 is specified and there is a 3.1.x runtime, then the highest available 3.1.x is used, which on my machine right now, would be 3.1.12.
- If 3.0 is specified but there are no 3.0.x runtime, then the highest available 3.x.x is used, which on my machine right now, would be 3.1.12.
Aside: Taking control of roll-forward behaviour
This is not directly related to the automatic updates but is good to know.
It is possible to override the default roll-forward behavior via run-time configuration. For example, on my system where I have 2.1, 3.1 and 5.0 installed, if I run an app targeting .NET 2.1 or 3.1 with the following, it will execute on the 5.0.3 runtime.
dotnet --roll-forward LatestMajor myApp.dll
Unaffected by automatic updates
Self-contained: As of Core 3.x it is also possible to distribute self-contained executables that include the required Core runtime.
Development teams must still track runtime versions used by these self-contained apps, follow the .NET Core and .NET 5 release metadata and make considered decisions about updating, rebuilding and redeploying.
Azure App servicing: These are still be patched automatically.
It is in an opt-in service. So on a client OS Receive updates for other Microsoft products when you update Windows must be enabled.
On server OS the updates are managed via Windows Server Update servicings (WSUS) or System Center Configuration Manager (SCCM). See the section for IT administrators on the MS blog for detailed instructions.
Barry Dorrans, ‘The .NET security person’ at Microsoft, https://twitter.com/blowdart/status/1234228333837078528 why .NET Core was not distributed as part of Windows:
1) We’d have to support that version for the lifetime of that Windows sku
2) It takes a lot longer to ship patches for Windows embedded code
3) It would probably mean an end to side by side runtimes
Right now we can turn around a security patch in a couple of weeks. If we had to insert into Windows that adds a minimum of a month, usually two depending on where we are in the month.
Obviously, updating is not the same as adopting Core as a component of Windows. It is nonetheless great to see we have overcome (or perhaps circumvented) the potential issues pulling .NET Core into Microsoft Updates (as opposed to Windows Updates).
There are no immediate plans to use Microsoft Update channels for major or minor versions also but if this does become a thing, the default roll-forward behaviour will ensure there are no breaking changes.
There’s loads more details in the .NET blog article from @jamshed.
Useful to know
- List installed runtimes with
- List installed SDKs with
- Uninstall a runtime, sdk or the hosting bundle with
dotnet-core-uninstallavailable to download here.
- Programatically have an app report which runtime it is using courtesy of Rick Strahl:
string runtime = System.Runtime.InteropServices .RuntimeInformation.FrameworkDescription;
I think in his article he got a
null from this but it worked correctly for me and was useful in proving to myself how the roll forward worked.