Can't load projects in solution

[ermshiperete]

Reproduction steps

I followed the instructions in CONTRIBUTING.md and installed the required .NET Core SDK and runtimes by running tools\Install-DotNetSdk.ps1 (I tried both with and without -InstallLocality Machine).

CONTRIBUTING.md mentions to use buildandtest.cmd to build and run the tests. I can't find that file anywhere.

Trying to open LibGit2Sharp.sln in Visual Studio 2019 (or Jetbrains Rider) fails to load the projects with:

15-04-2020 14:18:36	Critical	Some of the projects might not be read correctly. You may disable solution loading from disk or do that for certain projects.|   
Project 'LibGit2Sharp' load failed:
	[MSB4236] The SDK 'Microsoft.NET.Sdk' specified could not be found.  D:\Develop\libgit2sharp\LibGit2Sharp\LibGit2Sharp.csproj at (0:0)Project 'LibGit2Sharp.Tests' load failed:
	[MSB4236] The SDK 'Microsoft.NET.Sdk' specified could not be found.  D:\Develop\libgit2sharp\LibGit2Sharp.Tests\LibGit2Sharp.Tests.csproj at (0:0)Project 'NativeLibraryLoadTestApp.x86' load failed:
	[MSB4236] The SDK 'Microsoft.NET.Sdk' specified could not be found.  D:\Develop\libgit2sharp\NativeLibraryLoadTestApp\x86\NativeLibraryLoadTestApp.x86.csproj at (0:0)Project 'NativeLibraryLoadTestApp.x64' load failed:
	[MSB4236] The SDK 'Microsoft.NET.Sdk' specified could not be found.  D:\Develop\libgit2sharp\NativeLibraryLoadTestApp\x64\NativeLibraryLoadTestApp.x64.csproj at (0:0)

Deleting global.json allowed me to load the projects.

Version of LibGit2Sharp (release number or SHA1)

master branch: 4de700f

Operating system(s) tested; .NET runtime tested

Windows 10

Output of dotnet --info:

A compatible installed .NET Core SDK for global.json version [3.1.100] from [d:\Develop\libgit2sharp\global.json] was not found
Install the [3.1.100] .NET Core SDK or update [d:\Develop\libgit2sharp\global.json] with an installed .NET Core SDK:
  2.1.301 [C:\Program Files (x86)\dotnet\sdk]

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8

.NET Core SDKs installed:
  2.1.301 [C:\Program Files (x86)\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.1 [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.1 [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files (x86)\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.1 [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files (x86)\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[ermshiperete]

I think the reason was that I installed the 64-bit versions of the SDK, but VS was looking for the 32-bit versions. After installing the 32-bit versions the projects load even with the global.json file.

It seems that the Install-DotNetSdk.ps1 script is broken or the instructions need to be improved.

[bording]

What version of VS 2019 are you running? Assuming you're running the latest version, then the problem is that the global.json file needs to be updated. Version 16.5.x requires a 200 series SDK, but the global.json is still pointing at a 100 series SDK.

I had already fixed this in a PR that's being worked on and not yet ready to merge, but I'll look into getting the change into master as well.

[ermshiperete]

Yes, I'm running the latest version (Visual Studio 2019, Version 16.5.4).

[ermshiperete]

The other question is - is it really necessary to have a global.json file? It seems without it things would be a bit more flexible and work with a wider variety of environments.

[bording]

The other question is - is it really necessary to have a global.json file? It seems without it things would be a bit more flexible and work with a wider variety of environments.

It's a trade-off either way. Without it, you can run into problems where a new SDK release breaks things without being able to control when that happens.

The fact that different Visual Studio versions keep requiring specific SDKs does often seem to make the benefit of it more questionable though.

When we switched to Azure DevOps, part of the tooling around that @AArnott contributed also brought in the global.json stuff.

I'd have to look through that to see what impact there would be in removing it.

[AArnott]

It's a trade-off either way. Without it, you can run into problems where a new SDK release breaks things without being able to control when that happens.

Righto. In fact the last update 3.1.200 actually broke one of my repos. Fortunately I had a global.json file so that it kept working until I tried updating the global.json file, so I knew exactly what to blame when things broke.

The fact that different Visual Studio versions keep requiring specific SDKs does often seem to make the benefit of it more questionable though.

Ya, this doesn't sound right. It's not true, frankly. I use all sorts of SDK versions with VS and VS is fine with it. And the fact that installing the 32-bit version of the SDK making it work would also seem to defeat the theory that VS needed a later version.
But then, I've never had to install a 32-bit version of the SDK to make it work either. So I will investigate this more.

[bording]

Ya, this doesn't sound right. It's not true, frankly.

It's definitely true, otherwise they wouldn't release multiple versions of the SDK pointing out which version of the SDK you need to match the version of Visual Studio you're using.

See https://dotnet.microsoft.com/download/dotnet-core/3.1 for many examples of this.

[AArnott]

I don't think this is actually fixed. I don't have any 32-bit SDKs installed on my machine either and it works in VS 16.7.

@ermshiperete can you open a new command prompt and type dotnet --list-sdks and share its output?

[AArnott]

Ya, this doesn't sound right. It's not true, frankly.

It's definitely true, otherwise they wouldn't release multiple versions of the SDK pointing out which version of the SDK you need to match the version of Visual Studio you're using.

@bording How do you reconcile that with the fact that VS can load projects from all my repos that use a wide variety of SDKs?
I think you're misinterpreting that doc. It doesn't mean that VS can only support that SDK version.
The compatibility between VS and the SDK is actually the opposite direction. If you use msbuild.exe that came with VS to build your .NET SDK projects with a pinned global.json version, you need a new enough VS versoin for it to work. For example, you can't use VS 2017 msbuild.exe to load a .NET SDK 3.1 project. But going the other direction works fine: VS 2019 can load a .NET SDK 2.1 project.

[bording]

If you look at the 2.1 download page, it says "Visual Studio 2019 (v16.2 or later)" for the SDK 2.1.805 SDK. I take that to mean that it would work with any newer versions, but the 2.1.610 SDK wouldn't.

Are you saying you have projects that are actively locked to the 2.1.610, for example, that load properly in newer VS 2019 versions?

If so, that would indeed surprise me based on previous discussions I've had and seen elsewhere on GitHub.

[AArnott]

I've never met a VS version that couldn't load all prior SDK versions.

Just to make the point, I took a clone of https://github.com/aarnott/library.template, changed global.json from 3.1.201 to 2.1.513, and removed the netcoreapp3.1 target from the test app (since .NET SDK 2.1 can't target .NET Runtime 3.1). I then ran init.ps1 -installLocality repo and then opened the solution from that same window. VS came right up with all the projects opened.

So anyone who can't open a project with an older SDK due to an SDK error message is (in my experience) simply missing that particular SDK installation in every case.
I suspect @ermshiperete hasn't successfully installed the SDK machine-wide, or he has DOTNET_ROOT set to someplace else when he launches VS.

[bording]

I've never met a VS version that couldn't load all prior SDK versions.

Just to make the point, I took a clone of https://github.com/aarnott/library.template, changed global.json from 3.1.201 to 2.1.513, and removed the netcoreapp3.1 target from the test app (since .NET SDK 2.1 can't target .NET Runtime 3.1). I then ran init.ps1 -installLocality repo and then opened the solution from that same window. VS came right up with all the projects opened.

Interesting. That's definitely not what I would have expected based on everything I've read. I was under the impression that both VS and the SDK had minimum versions it would work with. Thanks for the new information!

Seems like something that should be clarified somewhere. Being able to point to a document that says that VS can work with all older SDKs would be nice.

[AArnott]

Maybe file a bug on the dotnet/sdk github repo asking them to be more clear on their get.dot.net web site?

[ermshiperete]

@ermshiperete can you open a new command prompt and type dotnet --list-sdks and share its output?

That's the current list of sdks (with which things work). See above for the list of sdks when it didn't work (after running tools\Install-DotNetSdk.ps1 and a reboot).

>dotnet --list-sdks
2.1.301 [C:\Program Files (x86)\dotnet\sdk]
3.1.103 [C:\Program Files (x86)\dotnet\sdk]
3.1.201 [C:\Program Files (x86)\dotnet\sdk]

[ermshiperete]

I suspect @ermshiperete hasn't successfully installed the SDK machine-wide, or he has DOTNET_ROOT set to someplace else when he launches VS.

I don't have DOTNET_ROOT set. Not successfully installed the SDK machine-wide - that was probably true, but that's what I thought tools\Install-DotNetSdk.ps1 should have done.

I then ran init.ps1 -installLocality repo and then opened the solution from that same window.

Where is running init.ps1 mentioned? Should that be run instead of Install-DotNetSdk.ps1?

It seems that the CONTRIBUTING.md doc is slightly outdated.

[AArnott]

You rebooted, @ermshiperete? But you only have 2.1.301 installed in the machine location (in your issue description), and this repo required 3.1.100 (until @bording's PR which bumped it to 3.1.201). So it's no wonder VS couldn't load your projects.
Had you opened VS immediately from the command prompt you used to install the .NET SDK with our script, it would have worked perfectly.

You must either use -InstallLocality Machine or launch VS from the same command prompt you ran our init script from. And no reboot is necessary.

I don't have DOTNET_ROOT set. Not successfully installed the SDK machine-wide - that was probably true, but that's what I thought tools\Install-DotNetSdk.ps1 should have done.

Install-DotNetSdk.ps1 did set the DOTNET_ROOT env var, at least if you installed in a lesser location than Machine. But that env var only is set in the powershell.exe process that ran the script.

Where is running init.ps1 mentioned? Should that be run instead of Install-DotNetSdk.ps1?

init.ps1 just runs Install-DotNetSdk.ps1 and then restores packages. So for your purposes, the two are equivalent.