Sdk: Uninstalling Visual Studio, should uninstall any .NET Core SDK that it installed

Created on 16 Jun 2017  路  38Comments  路  Source: dotnet/sdk

I'm forever cleaning up SDK installs in my add/remove, despite only ever installing/upgrading VS. This goes against the goals of the new Willow installer.

Uninstalling VS should uninstall a .NET Core SDK if no other component installed it. Other MSIs in VS uses a ref-count system to implement this - please make the .NET SDK do the same.

Most helpful comment

Yes, we are working on both the issue of old SDKs and easier ways to acquire the SDK.

All 38 comments

Just to flush things out a bit here, we should ONLY do this when that SDK was indeed installed by VS and only that specific version. What I mean is, if VS wants to install 1.0.4 and it is already installed on the box (and VS skips this install), when uninstalling, it should not remove that SDK.

Still, I would argue that we SHOULD not remove the SDK and if the user wants to do so, he should do it separately. The SDK works independently of VS.

All other MSI use ref-counting. It doesn't matter who installed it or when, the last one to uninstall, uninstalls it.

The SDK is not the only component that works independently of VS.

This is what ref-counting is supposed to do. The user install would be ref count 1, subsequent VS 2, VS uninstall drops to 1, leaving it installed.

I don't think the fact that it works independently from VS should matter. Chances are high that user who uninstalls VS wants to uninstall everything it installed (unless something bumped ref count). User can always install CLI again if they want. I think we're optimizing for the uncommon case as-is.

@davkean can you give me an example of other components in VS that behave like this? It would help with the code.

@nguerrera as long as we treat the user installation as a ref-count, I think we can discuss this.

cc @richlander

The portable library targeting pack is an example of this, but basically anything that is installed outside of the VS directory is in this bucket, as it becomes shared with multiple VS versions. Please reach out to the Willow folks on this - my knowledge about ref-counting is based on the previous installer, and it may have changed in the Willow world.

This seems a little excessive. Do we really need to keep every old version around when VS updates? (and this was after manually cleaning up all the pre-release versions!)

image

Dup of https://github.com/dotnet/cli/issues/6896.

Never mind, realized later this was just a comment on David's issue.

My SDK folder still looks like this:
image

Time to uninstall the 15 of the 16 SDKs on my machine right now:

image

image

For a VS Update, removing the previous SDK when an update is available could break builds (at least those that use global.json files to specify the SDK). So I'd prefer VS Update not remove the prior SDK version when it installs a newer one -- unless the prior one was just a -preview, in which case, remove away!

Let's get this prioritized. I am asking internally about how to actually make the code change.

Can there be CLI tool (built-in or independent) to gracefully uninstall previous SDK and runtimes? There can be options for uninstalling all previews, all-but-last in a minor version etc.

wasn't there some code back when it was dnx? like dnx upgrade to upgrade the cli. might as well just add options to drop preview sdk/previous minors

I think there are two separate problems:

VS not uninstalling the SDK: The relationship is complex enough I think we'd want to walk through the permutations carefully. Especially since a missing SDK may be silent if global.json roll forward just runs a different SDK.

Not uninstalling SDKs: It would be nice to have a dotnet uninstall with a few switches, including keeping any SDKs mentioned in global.json on a specified part of your box (with the warning of "patience required").

I also like the "uninstall previous" option on SDK install and the default uninstall of previews on release install.

default uninstall of previews on release install.

IMHO it would be great if devs could have option to keep previews as well.

@livarcocc any chance this could get assigned? Just freed up another couple of gigs on my machine by uninstalling old SDKs.

Are we living in 1995? Why is this seriously an issue?

Are we living in 1995? Why is this seriously an issue?

Space is cheaper yes, but unless Microsoft want to rent it, a bit of basic system hygiene in their updates wouldn't be greatly appreciated.

I'm just curious to know what's the status of this issue... @livarcocc @johnbeisner @davkean
Are you guys working on it? My desktop was almost running out of space, and when I went to Control Panel > Uninstall Programs, noticed there were tons of .net sdk versions as shown in above picture.

Also, is it possible to include a command in the CLI to upgrade the sdk version without needing to do the whole process manually (going to microsoft site, finding the latest version of the .net core sdk/runtime, downloading it, then installing it). I've raised this issue dotnet/cli#10270 for that effort.

Yes, we are working on both the issue of old SDKs and easier ways to acquire the SDK.

@KathleenDollard awesome, good to know!! Thanks for the update :+1:

@KathleenDollard any new updates?

Starting in Preview 3 of .NET Core 3.0, the Windows Installer treats each "feature band" as a single product and installs over previous copies. This means all versions of 3.0 will install over each other (preview and release), and then all versions of 3.1.

We hope to have a global tool that releases older tools later, but for now the existing SDKs must be removed by hand.

This means all versions of 3.0 will install over each other (preview and release), and then all versions of 3.1.

That sounds potentially very disruptive. We use global.json files to "pin" the SDK version used to build our product. Can we express just a major.minor version in that file? Right now we specify 3 integers in the version. So if 2.2.104 were to be uninstalled automatically when a VS Update or a newer SDK version is installed because 2.2.105 became available, that would break our build.

Can we express just a major.minor version in that file?

++.

The new install upgrade behavior stays within the same bands that global.json allows roll-forward, 3.0.2xx builds will not uninstall 3.0.1xx.

So if 2.2.104 were to be uninstalled automatically when a VS Update or a newer SDK version is installed because 2.2.105 became available, that would break our build.

This is not true. If 2.2.104 is not found, it will roll forward to latest 2.2.1xx > 2.2.104 that can be found.

Implemented for Visual Studio 16.3 Preview 1
https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequest/186888

@johnbeisner Is this available in Visual Studio for Mac?

@mrlife
Visual Studio for Mac has an uninstall process that should address the removal of an SDK - however, my understanding is that the uninstall is not a single gesture.
@GouriKumari
Can you point to the Visual Studio for Mac uninstall documentation.

@mrlife : This feature is not there for Visual Studio For Mac installer.

Was this page helpful?
0 / 5 - 0 ratings