Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chocolatey install/update removes *ALL* older SDK versions #42

Open
schuettecarsten opened this issue Aug 14, 2019 · 9 comments
Open

Chocolatey install/update removes *ALL* older SDK versions #42

schuettecarsten opened this issue Aug 14, 2019 · 9 comments

Comments

@schuettecarsten
Copy link

schuettecarsten commented Aug 14, 2019

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
Copy link
Contributor

flcdrg commented Aug 26, 2019

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

@riezebosch
Copy link
Member

riezebosch commented Sep 5, 2019

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
Copy link

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
Copy link
Contributor

flcdrg commented Sep 6, 2019

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
Copy link
Member

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
Copy link

EamonNerbonne commented Sep 6, 2019

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
Copy link
Contributor

flcdrg commented Sep 6, 2019

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
Copy link
Member

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

@riezebosch
Copy link
Member

This should probably resolve part of the problem: c7f9796

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants