Core: .NET Core Updates via Microsoft Update channels

[nakarnam]

Objective:
Offer .NET Core Updates for Windows Platform via the Microsoft Update Channels – Automatic Updates, WSUS and Microsoft Catalog.

Execution:
Scope includes .NET Core Runtime, SDK and the bundles (SDK plus Runtime), Hosting bundles, Desktop bundles, available via Automatic updates, WSUS updates and Microsoft Catalog. This is for both security and non-security updates. Minimum supported version is expected to be Win 7.

For automatic updates, the plan is to offer Opt-in functionality - once a user has opted in to receiving automatic .NET core updates, the default location will receive the new updates as they are released.

This will be independent of Visual Studio updates. .NET Core obtained via Visual Studio will continue to be updated by Visual Studio updates.

This proposal for Microsoft Update deployment is applicable to Framework dependent deployments only for .NET Core. For Self-contained deployments, where the .NET Core runtime is bundled as part of an application - the app developer is responsible for servicing this. We are working on ClickOnce support for .NET Core apps – more details at this issue.

[svick]

For automatic updates, the plan is to offer Opt-in functionality

How exactly will that work? Are you talking about this option?

Or is there going to be some .Net-specific option? If so, how is that going to be set?

[deathchurch]

Is there any rough timeline for the WSUS updating functionality? Are we talking .NET 5 or .NET 6 timelines?

[jamshedd]

@svick, here's our current thinking for the different user scenarios -

1. Enterprise deployment (WSUS/SCCM) -
   .NET Core updates will be available under a new Category in the WSUS console (these will not be updates to the Windows OS hence new category). a An enterprise admin would either (auto) approve the category or individual updates under the category. Additionally the admin would set a switch on the end user desktop to signal what types of updates should flow automatically (security fixes only, all fixes, major/minor, etc.) and the version(s) for which these should flow automatically. Current thinking for the switch is this could be a regkey since that's what we've done for Framework in the past) and its easy to deploy via group policy.

2. end-user (AU/Site) which is what you're referring to with that switch in your screenshot
   Customers would opt-in to MU itself. Additionally, the app that deploys the shared Framework (.NET Core installer) needs to set the switch to signal which updates should be automatically installed by MU. One can imagine the app developer would want servicing fixes to be installed automatically but would want to make an explicit choice about when to update to the next feature (major/minor) update.

[nakarnam]

@deathchurch this is being planned for the .NET 5 timeframe.

[deathchurch]

@svick, here's our current thinking for the different user scenarios -

1. Enterprise deployment (WSUS/SCCM) -

.NET Core updates will be available under a new Category in the WSUS console (these will not be updates to the Windows OS hence new category). a An enterprise admin would either (auto) approve the category or individual updates under the category. Additionally the admin would set a switch on the end user desktop to signal what types of updates should flow automatically (security fixes only, all fixes, major/minor, etc.) and the version(s) for which these should flow automatically. Current thinking for the switch is this could be a regkey since that's what we've done for Framework in the past) and its easy to deploy via group policy.

I assume the same method will be used for server deployment, this for me is where the real issue is rather than the desktop?

[ernstscheithauer]

@deathchurch this is being planned for the .NET 5 timeframe.

Since .NET Core 3.1 has long term support and .NET 5 will not, then it will take until .NET 6 to have a long term support version with WSUS/SCCM support. This is a downer, because as an ISV with annually upgrades at the customer sites any versions without long term support are hardly an option.

Could you therefore consider supporting .NET Core 3.1 with WSUS/SCCM as well?

[jamshedd]

I assume the same method will be used for server deployment, this for me is where the real issue is rather than the desktop?

WSUS/SCCM deployment will cover both client and server deployment.

[jamshedd]

Could you therefore consider supporting .NET Core 3.1 with WSUS/SCCM as well?

Yes - that's the plan :)

[bachratyg]

This will be independent of Visual Studio updates. .NET Core obtained via Visual Studio will continue to be updated by Visual Studio updates.

What is the patching strategy for Build Tools? I guess since it gets installed throug the same VS Installer as full VS it won't be updated through WU.

[jamshedd]

@bachratyg, if by build tools you mean the .NET Core SDK then that will be patched via MU as long as it was installed outside of of Visual Studio. If on the other hand you were referring to the VS build tools SKU then that is patched like any other VS SKU, via a VS update.

[bachratyg]

Yes, I meant the latter, thanks for the clarification.

VS Build Tools are usually installed on a CI server and as such out of sight. Would it be possible to install the SDK separately (that gets patched by MU) then install VS Build Tools that reuses the existing SDK installation instead of deploying its own? For the NET Core workload the SDK is mandatory.

[DM2489]

Will this fix sites being dead when new .NET core hosting bundles are installed on servers? We've had issues with the recent hosting bundles where installing them has killed off sites. It's been a nightmare to try and figure out why. When the issue strikes, we have to manually remove all instances of the .NET core hosting bundle from the affected server and manually install the latest bundle. It's highly annoying as it is inconsistent, takes sites offline.

[leonardder]

Is this still in scope for .NET 5.0?

[deathchurch]

Is there any further update to this now .NET Core 5 has been released?

[leonardder]

I'm also looking forward to an update on this, as our company is in the
process of deciding how to deal with .NET updates in the near and
distant future.

[jamshedd]

I wanted to share an update on this. We just shipped .NET 5.0 yesterday. As I mentioned earlier we're working on adding support for deploying updates for .NET Core 2.1, 3.1, and 5.0 via Microsoft Update. You're probably familiar with our "patch Tuesday" release cycle, we ship updates on the second Tuesday of each month, we plan to ship the first patch for .NET 5.0 on patch Tuesday i.e. 12/8, and it is our goal that we ship the patch (for Windows) via Microsoft Update in addition to the usual download channels.

We're furiously working on this and since the work is not all done there's a small possibility we don't make it in time for December or we find a last minute issue we need to address in which case we would deliver updates on MU starting January instead of December, but in either case this is coming pretty soon within the next 2 months.

We plan to put together a blog post detailing what you should expect in terms of experience and will get that out a week or so ahead of the first MU update.

[cremor]

The blog post is now up: https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/
Thanks!

[jamshedd]

Given that the work here is mostly done and we're expecting to ship 5.0.1 next week and MU updates for 3.1 and 2.1 in Jan I'm going to close out this issue now.