Can't support required SDK version in global.json due to patch version installation policy

[mikenunan]

We have picked a specific .NET SDK version (5.0.102) for our project using "rollForward": "disable" in our global.json so that we can ensure a consistent assembly set when our app is published, either locally or on the Azure DevOps build agents. As Visual Studio upgrades arrive on the desktop, they bring SDK patch version updates, so currently I have 5.0.104 and 5.0.102 has been removed.

If I try to reinstall 5.0.102 via the Windows installer, it fails with "Error 0x80070666: Cannot install a product when a newer version is installed."

I see from discussion here that this behaviour is by design, it's not possible to install a lower patch version from the same band. I have worked around this using the dotnet-install.ps1 script but given that the regular installer forbids this I'm concerned that having this older SDK side-by-side might be somehow problematic. If it isn't, then I suggest to remove this constraint from the installer to enable this use case.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[marcpopMSFT]

Installing the zips or using the install script is the only way to get a different patch version on the machine. As you've noted, we will always try to upgrade within the patch family. We don't currently have plans to change this behavior. There is no problem having the older sdk on the box and pinning to it other than you will not get security updates for that version so may have an at-risk application.

May I ask why you want to pin to a specific patch version rather than feature version? Most people when pinning versions pin to a feature band. Patched versions are almost exclusively security or high value fixes and should not have breaking changes. Are you concerned about both the runtime and the SDK changes?

[mikenunan]

@marcpopMSFT
Thanks for your response Marco and apologies for the slow reply as I'd missed the email notification on the issue until now. The issue is to do with build consistency on Azure DevOps build agents versus local workstation. The framework assembly names vary between patch versions, and in our environment we are building apps that are pushed to desktop via a proprietary system that requires a manifest with a full file list, which is committed to the source repo. If the framework files are named differently between the dev workstation and the ADO build agent, then one or other case will break at build time. Pinning the version resolves this and we can still move forward when we wish to, but in a coordinated fashion between team members and the build agents, rather than automatically with VS upgrade.

Stepping back, a cleaner solution to this would be to have consistent assembly names between patch versions. Comparing file sets between SDK versions 5.0.203 and 5.0.201, the only naming difference is this one:

mscordaccore_amd64_amd64_5.0.421.11614.dll (201)
mscordaccore_amd64_amd64_5.0.621.22011.dll (203)

Removing the version information from this filename would resolve the issue for us. Is there any reason why that would be a bad idea or difficult to accommodate?

[fschmied]

Joining this issue, as we've just experienced the same issue with KB5007051 (2021-10 .NET 5.0.11 Security Update for x64 Client), which updates 5.0.401 SDK to 5.0.402. Our motivation for fixating the patch version was because we had experienced different build behaviors (including build failures) between different patch versions in the past when different SDKs were installed on build agents vs. developer workstations, so we wanted to ensure consistent behavior.

[marcpopMSFT]

@jamshedd for visibility. Microsoft Update will update SDK patch versions as they include security fixes. You can use the install script or zip files to acquire specific older SDK versions if necessary but for our installers, our position is still to always move forward between patch versions on Microsoft Update and feature bands with VS updates. If you are seeing build failures between patch versions of the SDK, please report those issues so we can track them down as there should only be very narrow bug fixes and security updates in SDK patch version changes.

[jamshedd]

@jamshedd for visibility. Microsoft Update will update SDK patch versions as they include security fixes. You can use the install script or zip files to acquire specific older SDK versions if necessary but for our installers, our position is still to always move forward between patch versions on Microsoft Update and feature bands with VS updates. If you are seeing build failures between patch versions of the SDK, please report those issues so we can track them down as there should only be very narrow bug fixes and security updates in SDK patch version changes.

Marc is correct, pinning to a specific version is a run time behavior while Microsoft update deploying a patch to an existing SDK band is deployment time which happens before any code ever runs. From a patching perspective offering the newer SDK patch to a machine with a known vulnerability is the correct/expected behavior. As Marc said patch versions are expected to be highly compatible and if you're finding they're not you should report that so the appropriate folks can take a look.

[fschmied]

As Marc said patch versions are expected to be highly compatible and if you're finding they're not you should report that so the appropriate folks can take a look.

Okay, great, will do if we encounter such problems again. And switch to pinning the minor version instead.