Dotnet SDK auto-updates in Windows

[drk-mtr]

This is potentially more of a question regarding intended best practices and definitely isn't a bug, so apologies if this is the wrong place to ask.

Our development teams are using .NET 6 on Windows 10. When a new SDK version is released, Windows auto-updates. I don't recall auto-updates being applied before, I believe it was introduced in .NET 5, and this causes issues for us because a new version is not simply added - the old version is replaced. This messes things up when the global.json in the project roots specify a rollForward property of disable, to ensure that we're developing using the same versions as our build agents / app servers.

I appreciate this is configurable - apparently via the Receive updates for other Microsoft products when you update Windows setting in Windows - however I probably want updates for those other products.

Is there a recommended way to control this for dotnet SDKs specifically?

[adamsitnik]

@richlander PTAL

[richlander]

Good question. I'll ask.

Do you know that you can roll-forward on patch version. Is that acceptable to you?

[jamshedd]

@drk-mtr, we do provide the ability to not receive MU updates for .NET so you dont need to block all other updates. Take a look at this blog post about .NET updates coming to MU, and specifically the section on blocking these updates.

[richlander]

I read SDK vs Runtime not .NET vs no .NET.

[drk-mtr]

Thanks for the responses all, really appreciated!

@jamshedd Thanks - I have applied that registry change and will keep an eye on what happens. I'm not clear on whether this relates to the runtimes, the SDKs or both.

@richlander Do you know that you can roll-forward on patch version. Is that acceptable to you? I think quality and release controls are good enough on dotnet that this would be fine in 99.999999% of cases, but because I'm paranoid I like to try and ensure that nothing can change in CI pipelines unless we allow it to change. So I'm probably being OTT for the vast majority of cases, but my personal preference is to disable rollForward.

[joeloff]

@drk-mtr The registry entries applies to a specific update bundle, e.g. updates for .NET 6.0 or .NET 5.0. It doesn't allow for partially blocking specific components (child packages of the update bundle) like the SDK or one of the runtimes.

For CI scenarios, the zip copies of the SDK/runtime can be useful. For example, when we build the SDK itself, we acquire and create a local install of the runtime that won't get patched by MU, so we can retain full control, especially since we have tests that we want to run on older runtimes, e.g. we have tests for backwards compatibility for 3.1 and 5.0 when building the 6.0 SDK.

[marcpopMSFT]

I would add that our recommendation is that customers use the default roll-forward options with global.json which is latestPatch. Microsoft update will not update your SDK across feature bands so if you specify 6.0.300, you'll continue getting updates to the .300 band of the SDK but never be updated to .400.

Patches of the SDK do not contain breaking changes and every change is reviewed and approved individually. For the most part, the changes that are approved are high impact or security in nature. You're right that it's possible for something to slip through that we missed but I'm not generally aware of that happening to the patch releases. So using the default and pinning to a specific SDK feature band will keep you up to date with security fixes in the runtime and tools but limit your exposure to any riskier changes.

Some more details on our versioning can be found here

If you do want more control, Jacques suggestion of using the file-based installs will work but note that you'll be responsible for updating at that point and so could end up building with missing security fixes.

[drk-mtr]

Thanks again all! Lots of good info here - I'll have a play and will most likely recommend latestPatch as best practice.

[drk-mtr]

I've just started having a play around and I've realised that using latestPatch will result in our build pipelines breaking every time the feature is incremented, which is quite often.

The ideal for me would be that the build agents have multiple versions of the latest LTS available by default i.e. latestPatch, latestFeature and latestMinor. This would avoid additional (potentially time-consuming) steps to copy across zips, or tasks to install a different SDK during build.

Using latestFeature for now as a compromise but not entirely comfortable with it.

[richlander]

I've just started having a play around and I've realised that using latestPatch will result in our build pipelines breaking every time the feature is incremented, which is quite often.

Can you elaborate? I'm not following.

[reduckted]

@marcpopMSFT Patches of the SDK do not contain breaking changes and every change is reviewed and approved individually. For the most part, the changes that are approved are high impact or security in nature. You're right that it's possible for something to slip through that we missed but I'm not generally aware of that happening to the patch releases.

Unfortunately that's exactly what happened with 7.0.202. See dotnet/runtime#83526. It contained a change that actually broke assembly loading for me, which means I'm stuck on 7.0.201 for the time being. Thankfully the registry setting in #7457 (comment) works beautifully and I no longer have Windows Update trying to uninstall 7.0.201. 😁

[NickDarvey]

@marcpopMSFT

If you do want more control, Jacques suggestion of using the file-based installs will work but note that you'll be responsible for updating at that point and so could end up building with missing security fixes.

Which method should I be using for file-based installs? The docs don't mention it. (I can't see a comment by a Jacque in this thread either.)

It contained a change that actually broke assembly loading for me

Similar situation for us. Breaks happen, we'd like repeatable builds across developer machine and build agents by using the exact same version.

I appreciate this is configurable - apparently via the Receive updates for other Microsoft products when you update Windows setting in Windows - however I probably want updates for those other products.

Is there a recommended way to control this for dotnet SDKs specifically?

I have the same request as the initial request. Can we reopen this issue?

[marcpopMSFT]

You can use the install scripts or appropriate binary link on the download page to download the zip/tar files.

We currently do not have plans to change the current upgrade behavior of Visual Studio or Windows Update though we constantly reassess as we get feedback.

[tijmenpitcrew]

I think the current bugged .NET 6 SDK release 6.0.422 illustrates the need for control over the installed SDKs. Every time I reboot my development machine I need to uninstall 6.0.422 and reinstall 6.0.421 because of dotnet/roslyn#73536 as reported by dotnet/roslyn#73510 .