Visual Studio Installer removes 8.0 SDK

[mstv]

Describe the bug

I have updated the Visual Studio Community 2022 to 17.12.2 using the Visual Studio Installer.
This has deinstalled all instances of the 8.0 SDKs.
The remaining SDKs are 6.0.428 and (the new) 9.0.100.
This occurred on 2 of 2 machines.

To Reproduce

• have installed Visual Studio 17.10.x or 17.11.x (not sure)
• update to 17.12.x

Exceptions (if any)

> dotnet build

Requested SDK version: 8.0.0
global.json file: F:\Build\gitextensions3\global.json

Installed SDKs:
6.0.428 [C:\Program Files\dotnet\sdk]
9.0.100 [C:\Program Files\dotnet\sdk]

Further technical details

> dotnet --info
.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.4a280210
 MSBuild version:   17.12.7+5b8665660

Laufzeitumgebung:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.100\

Installierte .NET-Workloads:
Es sind keine installierten Workloads zum Anzeigen vorhanden.
Konfiguriert für die Verwendung loose manifests beim Installieren neuer Manifeste.

Host:
  Version:      9.0.0
  Architecture: x64
  Commit:       9d5a6a9aa4

.NET SDKs installed:
  6.0.428 [C:\Program Files\dotnet\sdk]
  9.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.30 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.17 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 9.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  arm64 [C:\Program Files\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation]
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

[willdean]

I had this happen too, using VS2022 Enterprise. I would have been on a late 17.11 release beforehand.

[baronfel]

This has been our practice for many releases now - the thinking is that since SDKs can target any TFM users should have the most up to date tooling at all times.

You can still create net8.0 libraries and applications using this SDK, can you clarify what other problems the 9 SDK introduced from your point of view?

[mstv]

Several projects request the SDK version including the patch number, i.e. "8.0.0". They do not build with the 9 SDK unless this is relaxed to "8.0" - which still feels counterintuitive.

(For curiosity: Why has the 6.0 SDK not been uinstalled, too?)

[willdean]

can you clarify what other problems the 9 SDK introduced from your point of view?

dotnet watch is broken in 9.0.0 is the most obvious one.
But regardless of that, we have global.json files all over the place which look like this:

{
  "sdk": {
    "version": "8.0.100",
    "rollForward": "latestFeature",
    "allowPrerelease": false 
  }
}

And a project under that kind of global.json will not build if the 8.0 SDK is missing.

It's not a very big deal, because it take only a few seconds to download and re-install 8.0.

[baronfel]

Thanks for the details! Is it fair to say that you expect all the tooling you use to adhere to your global.json?

[mstv]

I stripped the project path from the issue description. I tried to compile https://github.com/gitextensions/gitextensions, which used to work all the years before.

[willdean]

Is it fair to say that you expect all the tooling you use to adhere to your global.json?

I suppose in general terms it's fair to say that I expect global.json to allow me to install the latest version of VS/.NET without the risk that doing so will break existing projects / workflow if it turns out that the new version is "not quite as good as I hoped."

It's moot whether it's the libraries or the tooling which cause breakage. If the tools didn't adhere to global.json then I would have uninstalled 9.0.

[baronfel]

For future reference, VS ships with and is intended to be compatible with specific versions of the SDK, as documented here: https://learn.microsoft.com/en-us/dotnet/core/porting/versioning-sdk-msbuild-vs#lifecycle

For best results these versions should be kept in sync. We are hoping to work on decoupling VS and the SDK a bit more, but at the moment there is a fairly tight coupling.

[RussKie]

Thanks for the details! Is it fair to say that you expect all the tooling you use to adhere to your global.json?

It is fair to expect the update to an IDE not to mess the whole dev environment, yes. The current VS behaviour of uninstalling the SDKs is rather disturbing.

[dsplaisted]

Here's how this works (or is supposed to):

If Visual Studio installs the .NET SDK, then that SDK is "owned" by VS, and when VS updates to a newer SDK it will uninstall the old one. Otherwise, over time VS would leave a bunch of .NET SDK installs behind.

If you install the SDK outside of VS (even if it's the exact same version that VS already installed), then that version won't be uninstalled when you update VS (the installs are ref-counted).

So if you pin a version in global.json, you should install that version with the standalone .exe installer, so VS won't uninstall it out from under you.

@baronfel @marcpopMSFT Do we have this documented in a good place?

Note: The original issue said that VS uninstalled "all" versions of 8.0. I would only expect there to be one VS-managed version of the .NET SDK, and at most one version to be uninstalled by VS during an upgrade. If there were multiple 8.0 versions installed side-by-side and more than one of them was uninstalled, then it's possible something else is going on.

[mstv]

Note: The original issue said that VS uninstalled "all" versions of 8.0.

Empty folders have been left behind. These might have been emptied by previous VS updates. As this did not break the request for 8.0.0, I did not notice it.

[marcpopMSFT]

@dsplaisted @baronfel here's a doc update that calls out this behavior specifically: dotnet/docs#43866

It's still not clear to me why customers are willing to update their VS which is their development environment but draw the line at the SDK which is only a small portion of the tools used when developing in VS.

[marcpopMSFT]

@willdean if you don't mind sharing what is broken with dotnet watch with @tmat or filing a separate issue for that, that would be helpful: #45241 (comment)

[mstv]

It's still not clear to me why customers are willing to update their VS which is their development environment but draw the line at the SDK which is only a small portion of the tools used when developing in VS.

Have you ever tried to bisect, i.e. to build older commits? I primarily see VS as an IDE, i.e. a GUI. An update of a (powerful) editor shall not require changes to existing code - at least not in minor updates.

[marcpopMSFT]

Have you ever tried to bisect, i.e. to build older commits? I primarily see VS as an IDE, i.e. a GUI. An update of a (powerful) editor shall not require changes to existing code - at least not in minor updates.

I appreciate the context. Visual Studio is not just a GUI though as if you're building in VS, you're getting an updated compiler, msbuild, nuget, and testing tools that all come with the VS install. So you're already updating 80% of your development tools even if you don't think of it that way. I think you're right that some customers don't realize or see it that way and hence wanting to stay on an older SDK even when they are updating all the rest of their development tools.

[RussKie]

Here's how this works (or is supposed to):

If Visual Studio installs the .NET SDK, then that SDK is "owned" by VS, and when VS updates to a newer SDK it will uninstall the old one. Otherwise, over time VS would leave a bunch of .NET SDK installs behind.

If you install the SDK outside of VS (even if it's the exact same version that VS already installed), then that version won't be uninstalled when you update VS (the installs are ref-counted).

Note: The original issue said that VS uninstalled "all" versions of 8.0.

Empty folders have been left behind. These might have been emptied by previous VS updates. As this did not break the request for 8.0.0, I did not notice it.

All the deleted SDKs were part of the VS installation (see https://dotnet.microsoft.com/en-us/download/dotnet/8.0), so it's by design.

[willdean]

@willdean if you don't mind sharing what is broken with dotnet watch with @tmat or filing a separate issue for that, that would be helpful: #45241 (comment)

There are a number of bugs open already both here and in the aspnet repo about dotnet watch with Blazor - I think there are several fixes coming.

[ToreDemant]

We just experienced this too upgrading from VS 17.10.9 to VS 17.12.3

It removed .Net 8 SDK that our source code targets. We do not have plans to shift framework until .Net 10 and even at that point we would still need to build older branches that keep targeting .Net 8. We try to stay up-to-date with Visual Studio versions, but usually only jumps to the next LTS version, but we do expect to be able to keep targeting existing .Net version between updates.

Is .Net 8 really an older SDK? I believe that it has support until November 2026.

[mstv]

Just download the 8 SDK and install it in addition.