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