Language server does not support .NET 5 SDK

[bamarsha]

Describe the bug

After installing the .NET 5 SDK, the language server can't load Q# projects:

[Info - 12:15:44] workspace folder: c:\Users\samarsha\Desktop\QSharpSandbox [Error - 12:15:45] Error on loading project 'c:\Users\samarsha\Desktop\QSharpSandbox\Library\Library.csproj': Der SDK-Resolvertyp "WorkloadSdkResolver" konnte nicht geladen werden. Could not load file or assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Das System kann die angegebene Datei nicht finden. c:\Users\samarsha\Desktop\QSharpSandbox\Library\Library.csproj. Ignoring non-Q# project 'c:\Users\samarsha\Desktop\QSharpSandbox\Library\Library.csproj'. [Error - 12:15:45] Error on loading project 'c:\Users\samarsha\Desktop\QSharpSandbox\App\App.csproj': Der SDK-Resolvertyp "WorkloadSdkResolver" konnte nicht geladen werden. Could not load file or assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Das System kann die angegebene Datei nicht finden. c:\Users\samarsha\Desktop\QSharpSandbox\App\App.csproj. Ignoring non-Q# project 'c:\Users\samarsha\Desktop\QSharpSandbox\App\App.csproj'. [Info - 12:15:45] The file c:\Users\samarsha\Desktop\QSharpSandbox\App\App.qs is not associated with a compilation unit. Only syntactic diagnostics are generated.

To Reproduce

Steps to reproduce the behavior:

1. Open a Q# project in VS Code

System information

• QDK extension v0.13.20111004 for VS Code
• Windows 10, .NET 5.0.100
• VS Code 1.51.1

Additional context

The Q# project file is:

<Project Sdk="Microsoft.Quantum.Sdk/0.13.20111004">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <QscVerbosity>detailed</QscVerbosity>
  </PropertyGroup>
</Project>

The project builds and runs successfully from the command line.

[bamarsha]

Note that just having .NET 5 installed is enough to break the language server, even if I also have .NET Core 3.1 installed, and the Q# project is targeted for .NET Core 3.1. Temporarily removing the C:\Program Files\dotnet\sdk\5.0.100 folder makes the language server work again.

[bamarsha]

Possibly related issues:

• microsoft/MSBuildLocator#92
• dotnet/roslyn#49248
• dotnet/tye#699

[bamarsha]

A workaround is to add a global.json file to your Q# project, or to any parent directory (such as your user directory), that sets the .NET SDK version to 3.1:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "latestFeature"
  }
}

[bettinaheim]

A workaround is to add a global.json file to your Q# project, or to any parent directory (such as your user directory), that sets the .NET SDK version to 3.1:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "latestFeature"
  }
}

@samarsha It might make sense to just add such a global.json to our project templates. What do you think?

[bamarsha]

I think if we can't find any other solution to support .NET 5 and .NET Core 3.1 simultaneously, then adding global.json to the project template would make sense. But it seems like a last resort to me. Ideally, we would even support having only .NET 5 SDK installed (not .NET Core 3.1 SDK), since dotnet build from the command line already works in that scenario (with a Q# project targed to netcoreapp3.1).

[cgranade]

I think if we can't find any other solution to support .NET 5 and .NET Core 3.1 simultaneously, then adding global.json to the project template would make sense. But it seems like a last resort to me.

Agreed. Even if providing a global.json may be a good idea for individual projects to do in order to enable reproducible builds, it's a big step for us to require that of our users.

Ideally, we would even support having only .NET 5 SDK installed (not .NET Core 3.1 SDK), since dotnet build from the command line already works in that scenario (with a Q# project targed to netcoreapp3.1).

Agreed here ass well.

[vxfield]

PR #755 (and corresponding #753 for the Nov release) mitigates this issue by:

1. Adding a global.json in the LanguageServer folder
2. Forcing the Working Directory of the LanguageServer to be the same as the. LanguageServer is (and. therefore using the global.json from step above)
3. Not quitting the LanguageServer if there was an issue with the MSBuildLocator when .NET Core SDK 3.1 is not found
4. Check if .NET Core SDK 3.1 is not installed and display a message to the user with an option to download it (opens the download page) and asking the user to restart VS/Code.

[cgranade]

Does that imply that we need to add in documentation that .NET SDK 5 is not supported unless .NET Core SDK 3.1 is also installed? Is there a path towards relaxing that in the future, or will we require that mitigation until the next LTS (.NET 6 in November 2021)?

[bamarsha]

I'm not sure if the fix for microsoft/MSBuildLocator#92 means that .NET Core 3.1 SDK will be automatically selected without a global.json, or if it will actually work without .NET Core 3.1 SDK installed.

[rainersigwald]

I mentioned this in microsoft/MSBuildLocator#117 but to be super clear: if you want to support working on machines that have only the .NET 5.0 SDK installed, you'll have to target .NET 5.0.

[bamarsha]

This is blocked until our QDK build pipeline is updated to build with .NET 5.

[bettinaheim]

@ricardo-espinoza Can this be closed with the .NET 6 update?