Solution to Visual Studio 2022 messing up Visual Studio 2019

As all .NET developers I am quite excited by Visual Studio 2022 and .NET 6 going RTM. However I noticed that Visual Studio 2022 RTM install messed up Visual Studio 2019. Our .NET 5 and .NET Standard 2 projects couldn’t be loaded anymore in Visual Studio 2019. The error shown when attempting to load the projects was:

The project file cannot be opened. Unable to locate the .NET SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.

Hamid Mosalla compiled solutions to this problem in a great post. However none of those solutions worked. After an hour googling and tweaking I found the solution here VS2022 RC Install messed up my Android Xamarin projects in VS2019. In your system environment variable path, Visual Studio 2022 put C:\Program Files (x86)\dotnet\ before C:\Program Files\dotnet\. Just restore the right order et voilà 🙂

Btw to access this dialog go to : Window > Control Panel > Edit the system environment variables, then locate the variable Path in the list, select it and click the Edit button.

The solution is not intuitive at all and I hope this post will save you some time!

Edit:

Marc Payne from Microsoft DevDiv contacted me and wanted to add these details here:

–“First off, I’d like to say thank you for writing up the summary of the issue here as the more places this is posted, the more likely people are going to be able to find and fix their problem.

One note I’d make is that I recommend developers run dotnet –info  and it might be good to call that out in your post for diagnosis.  A lot of customers are running dotnet –list-sdks and the problem with that is most customers in this situation have runtimes installed in c:\program files (x86)\dotnet (as VS includes the x86 runtimes) but no sdks so no results are returned. If you do dotnet –info instead, it’ll list all of the runtimes it finds in the (x86) path which will make it a bit more obvious for customers to confirm that they’re in this bad state.

Also, this is our known issue for this item if you wanted to link to that as well. core/known-issues.md at main · dotnet/core (github.com). We’ve identified the cause and are currently working on options for a solution.  Thanks.”–

Edit: 23th November 2021, more feedback form Marc Payne

From our data, ~1% of SDK customers end up installing the x86 SDK. Visual Studio only installs the x64 and x86 runtimes but doesn’t include the x86 SDK or host. So even for customers who install the x86 SDK, we wouldn’t want the x86 host used in Visual studio as we haven’t tested that.

Anyway, we released a fix with 17.0.1 that removes the x86 dotnet host path during install. Because Visual Studio doesn’t install the x86 host itself and was not tested with the x86 host, this felt like a relatively low risk option and we haven’t seen negative feedback since related to that. We’ll be removing that workaround in a December release when we can get the x64 host to correctly upgrade without uninstalling the PATH first (which was the crux of the original issue causing the x86 and x64 path entries to flip their order).

By running dotnet –info on my dev machine with C:\Program Files (x86)\dotnet\ before C:\Program Files\dotnet\ (the bad state) I get:

By running dotnet –info on my dev machine with C:\Program Files\dotnet\ before C:\Program Files (x86)\dotnet\ (the right state) I get:

Edit:

• Alternatively you can delete the x86 version of the SDKs.
• Also a user reported: I had completely different behavior when I switched the 2022 Preview to Current. It removed All the x86 dotnet Sdks! I had to reinstall 3.1 x86 to get vs2019 to be able to load sdk style projects.