Chocolatey install/update removes *ALL* older SDK versions

[schuettecarsten]

When installing/updating the chocolatey package, ALL older SDK versions are uninstalled.

This includes versions like 2.2.205 which are still required on some machines due to global.json files not rolling up from 2.2.2xx to 2.2.4xx. This is causing a breaking change on install. I understand net core 3 does something similar, but that should only be for versions covered in the same "version" like 2.2.205 install would uninstall all other 2.2.20x versions, not a 2.2.10x version though.

Please note the discussion in the comments section at https://chocolatey.org/packages/dotnetcore-sdk/

[flcdrg]

Agreed. This is not a good thing. It is normal to require multiple versions of .NET Core SDK to be installed.

[riezebosch]

When looking into this I found out the chocolateybeforemodify of current installed package is executed and that version is the only variable available. This makes it impossible to inspect the differences between the current and the target version number.

It seems to me that chocolatey is not very well suited to the stupid versioning scheme that is used by Microsoft. Probably the best we could do is deploy separate packages matching the Visual Studio version that it is used for. But I'm not sure if we can use virtual packages for that and how side-by-side packages works for dependencies and strictly speaking the versions are not tight to a Visual Studio version I guess.

[EamonNerbonne]

Frankly it'd be better to simply not uninstall at all than have the current behavior. I think that's a serious option: it's a mess to leave behind all those files, but that's probably better than breaking stuff. And as @riezebosch points out, there's no simple way to detect what can go and what needs to stay.

Another alternative would be to have multiple choco packages, one for each conceptually major version, but that's a pain too, and breaks the upgrade workflow.

[flcdrg]

To be honest, multiple packages may be a better option as in reality, upgrading .NET Core SDKs doesn't really make sense outside of the patch version incrementing.

So 2.2.200 should upgrade to 2.2.201, but shouldn't upgrade to 2.3.100 - that should install side-by-side

[riezebosch]

To be honest, multiple packages may be a better option as in reality, upgrading .NET Core SDKs doesn't really make sense outside of the patch version incrementing.

So 2.2.200 should upgrade to 2.2.201, but shouldn't upgrade to 2.3.100 - that should install side-by-side

What would be cool is virtual package with an exact version match for that.

Frankly it'd be better to simply not uninstall at all than have the current behavior. I think that's a serious option: it's a mess to leave behind all those files, but that's probably better than breaking stuff. And as @riezebosch points out, there's no simple way to detect what can go and what needs to stay.

Another alternative would be to have multiple choco packages, one for each conceptually major version, but that's a pain too, and breaks the upgrade workflow.

Maybe I can uninstall only from that package range because of course, you don't need to know the target version for that. Only uninstall packages in current range instead of all.

[EamonNerbonne]

To be honest, multiple packages may be a better option as in reality, upgrading .NET Core SDKs doesn't really make sense outside of the patch version incrementing.

As a consumer of packages that makes sense - but I'm not sure how you'd want to implement that, because their numbering scheme isn't semver or anything. Each conceptually major version would need some kind implementation to match all packages in its conceptually major range, and that concept may be tricky enough to cause annoying bugs not to mention be a lot of work to implement.

And even then, you'd be making choco upgrade less useful, because you wouldn't even be able to detect that a new major version is out nor have any way of knowing that new major version's package name.

I mean I'd love to see that as a user! But... I'd be content with simply not having build machines break on choco upgrade, and the rest is gravy.

[flcdrg]

If you did go to separate packages, then possibly the existing dotnetcore-sdk ones could become virtual ones that pointed to actual separate ones (for people who wanted to keep using dotnetcore-sdk)

As it is now, I need to remember to use the -m flag when installing new versions of dotnetcore-sdk so they all live side by side.

If they were separate packages, then the semver would probably work as expected..

eg. given a package named dotnetcore-sdk-2.2.30x, you could have versions 2.2.300, 2.2.301, 2.2.302 etc.

[riezebosch]

Until Microsoft decides to bowl over the versioning scheme once again or they move over to a single update channel on 3.0 ¯_(ツ)_/¯

[riezebosch]

This should probably resolve part of the problem: c7f9796