Updating VS 2019 from 16.3.x to 16.4.0 uninstall existing .NET Core SDK 3.0.100

[eriawan]

I have 2 different machines that has VS 2019 16.3.10 and VS 2019 16.3.7 on Windows 10 1909.
Both of them have .NET Core SDK v3.0.100 installed.

After I update to VS 2019 16.4.0, the .NET Core SDK v3.0.100 got uninstalled and .NET Core 3.1.100 is installed. I don't mind having .NET Core 3.1.100 SDK installed.

My problem is why .NET Core 3.0.100 is uninstalled on every time I update VS 2019 from v16.3.x to v16.4.0?

[johnbeisner]

@eriawan
.NET Core 3.1.100 supports 3.0, 2.2, & 2.1
We have designed .NET Core with Visual Studio to only have a single SDK toolset - typically the most current released SDK. However, we are aware of an installation BUG that removes the 3.0 Runtimes on this upgrade gesture - is this your concern?

[eriawan]

@johnbeisner
Yes, that's my concern. Is there a planned schedule to fix this?

[johnbeisner]

@eriawan
We have fixed this for 16.5 and future releases; 16.3 and 16.4 will still have this update gesture problem. The workaround is to modify your VS installation and add back the desired Runtimes from the 'Individual component' list.

[NickCraver]

My team has hit this with every project as well, and we've had to alter every global.json in every repo for everyone that upgraded. It's not an awesome experience.

We have/had a global.json like so (in dozens of repos) like so:

{
  "sdk": {
    "version": "3.0.100"
  }
}

...to which we had to add "rollForward": "latestMajor". While it's great there's a mechanism for this, the experience on upgrading is really crappy for developers. The VS installer leaves the C:\Program Files\dotnet\sdk\3.0.100 directory in place, so it's a broken SDK. e.g. this is what you got at the console after the VS upgrade:

λ dotnet --version
Found .NET Core SDK, but did not find dotnet.dll at [C:\Program Files\dotnet\sdk\3.0.100\dotnet.dll]

...that's a very confusing experience (and I'm hoping a bug - but I've hit this several times in upgrades now). Half of this is because it was removed, but it wasn't totally removed and since SDK version detection works on "is the folder there?", Visual Studio breaks pretty bad here and I've gotten a lot of requests for help from devs across the company on this. Here's their experience after the upgrade to 16.4:

After they close that...

I was a fan of the VS installer removing all of the preview releases when this was pitched. Huge fan. I racked up many gigs on SDKs. But in practice, this has caused more pain than it removed. I ask this: Can we please only uninstall/cleanup the same minor version?

Without that scope, I have to either go re-install the SDK (which really defeats the purpose here), or go change the global.json in every repo. Neither of those are good for me or my team, and this cleanup feature becomes a burden rather than a help.

---

If anyone wants to repro the user experience:

1. Set a specific version of an SDK not installed in your global.json (with no roll forward), e.g. 3.0.100
2. Create that empty directory, e.g. on Windows C:\Program Files\dotnet\sdk\3.0.100
3. Try and open the solution
   ...and you'll get the behavior in the screenshots above. This is unfortunately what the VS install experience does by default - hoping we can improve that!

[NickCraver]

cc @KathleenDollard @danroth27 ^ This is a follow-up to some discussions we had about upgrade pain points the whole team has felt, documenting it here.

[clairernovotny]

More in this thread https://twitter.com/onovotny/status/1206224178921246720

IMO, the current behavior is good and desirable. The later SDK's have new features, fixes and still allow building the current and previous targets.

What might be missing is a way in global.json to opt-in/out of using preview SDK's but without specifying a version number. That way, if any preview SDK is on the machine, for a particular project, it'll fallback to using the latest stable instead of latest preview, etc.

[NickCraver]

I think it's also worth bringing up here: people came to me on how to fix this because the global.json docs still don't have any fixes or suggestions around this. rollForward remains undocumented AFAIK.

For example, there exists a allowPrerelease like Oren mentions above, but you really have to be involved here to know that exists.

Here are the docs: https://docs.microsoft.com/en-us/dotnet/core/tools/global-json
And here is the issue about none of the 3.0 features being in there: dotnet/docs#14479

[MeikTranel]

I don't think the documentation to that really is enough. I am almost certain that the majority of .net developers do not know anything about global.json at all. Most .net people in my social circle still think of the solution file as the center point to migrating tooling (which has some merit, which is making this experience even worse).
I've been helping with a bunch of library authors migrating their tooling to new csprojs etc. and the overwhelming response was "meh i will not touch this file again for the next gazillion years... the sln file says 2019 now tho -> approve, squash and merge". This is not healthy at all.

[mairaw]

Regarding the docs, I have a PR in progress that I’m planning to finish this week: dotnet/docs#15382

It needs more examples and explanations of the behavior changes starting in 3.0.

[mariusGundersen]

I'm having problems after upgrading to VS 16.4.1, and I don't have a global.json file. I have hundreds of errors in my small project, but it seems like the one that causes most of them is

Error	NETSDK1073	The FrameworkReference 'Microsoft.NETCore.App' was not recognized	My.Project	C:\Program Files\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets	283	

I have csproj files with <TargetFramework>netcoreapp3.0</TargetFramework> and the don't load correctly anymore. Cleaning does not seem to help, and setting it to use netcoreapp3.1 does not help either. I'm going to try installing 3.0.101 and see if that helps.

Edit: this is what I have installed now. The cleanup doesn't seem to be very helpful...

C:\>dotnet --list-sdks
1.0.0-preview2-003131 [C:\Program Files\dotnet\sdk]
1.0.0-preview2-003156 [C:\Program Files\dotnet\sdk]
1.0.0 [C:\Program Files\dotnet\sdk]
1.0.2 [C:\Program Files\dotnet\sdk]
1.0.3 [C:\Program Files\dotnet\sdk]
1.0.4 [C:\Program Files\dotnet\sdk]
1.1.0 [C:\Program Files\dotnet\sdk]
2.0.0-preview1-005977 [C:\Program Files\dotnet\sdk]
2.0.0 [C:\Program Files\dotnet\sdk]
2.0.2 [C:\Program Files\dotnet\sdk]
2.0.3 [C:\Program Files\dotnet\sdk]
2.1.2 [C:\Program Files\dotnet\sdk]
2.1.3 [C:\Program Files\dotnet\sdk]
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.104 [C:\Program Files\dotnet\sdk]
2.1.200 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.300-rc1-008673 [C:\Program Files\dotnet\sdk]
2.1.300 [C:\Program Files\dotnet\sdk]
2.1.400 [C:\Program Files\dotnet\sdk]
2.1.402 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.500 [C:\Program Files\dotnet\sdk]
2.1.700 [C:\Program Files\dotnet\sdk]
2.2.105 [C:\Program Files\dotnet\sdk]
2.2.301 [C:\Program Files\dotnet\sdk]
2.2.402 [C:\Program Files\dotnet\sdk]
3.1.100 [C:\Program Files\dotnet\sdk]

[abelbraaksma]

This behavior proves very problematic in practice. In the past, SDK's were left alone when updating, but at some point, SDK's were uninstalled when updating through the VS Installer. While this is trivial to fix once you know it (just download the SDK's by hand), it leads to very unwelcome surprises, like SDK-dependent solutions (through global.json etc) not loadable anymore inside VS.

I suggest this be fixed somehow. I can imagine making it a choice in the uninstaller (just ask the user), or going back to the previous behavior by simply leaving these SDK's alone.

Adding it as an option when you select "Update" would probably be the best way forward.

[sake402]

Just to note that I updated VS2019 to version 16.8 and viola, all my existing SDKs gone and replaced with 5.0.
Not everyone will be willing to jump right to dotnet 5, at least not until we are sure it is stable enough for production.
Nothing a fresh download of 3.1.404 cant fix, but this can't happen everytime VS2019 is updated. In my opinion, VS doesn't own dotnet binaries and should just leave the existing SDKs alone.

[redwyre]

This just happened AGAIN, please stop uninstalling sdks! I updated vs and build tools on a build machine and it broke all my builds!

If you want to uninstall old SDKs, ASK FIRST

[velvetdust]

This just happened AGAIN, please stop uninstalling sdks! I updated vs and build tools on a build machine and it broke all my builds!

same thing here:
Found .NET Core SDK, but did not find dotnet.dll at [C:\Program Files\dotnet\sdk\5.0.202\dotnet.dll]

[redwyre]

AND AGAIN

Updating removed 5.0.1xx when installing 5.0.3xx, breaking all existing builds again

[mairaw]

Tagging @timheuer

[KathleenDollard]

Visual Studio uninstalls what it installs on an update. I understand that it is causing an inconvenience, but the alternative is to have Visual Studio not clean up after itself that would also be bad.

If you install via the SDK installer by downloading Visual Studio will not uninstall. We use normal Windows installer ref counting and separately ref count VS and the CLI, so after VS updates itself the ref count for the CLI remains and will block the uninstall of the earlier version.