Unable to load projects on .NET SDK 6.0.301 due to NuGet.Frameworks load errors

[baronfel]

Describe the bug

The language server extension bundles a version of NuGet dlls that is incompatible with the ones shipped in the SDK. Because MSbuild Locator is used to locate and run MSBuild DLLs from the SDK, there are version mismatches that lead to errors running targets in the build.

This was initially reported at dotnet/sdk#26065, with detailed resolution steps here.

To Reproduce

Please see the linked issue for reproduction steps.

Expected behavior

The language server should be able to load projects.

System information

• Version of the NuGet package or extension for which the problem occurs: v0.24.210930
• Your operating system and .NET Core version: Ubuntu 22.04, .NET SDK 6.0.301
• For issues with extensions, the version of the IDE for which the problem occurs: Visual Studio Code version 1.68.1

Additional context

The short form of the resolution is that the NuGet.Frameworks PackageReference in the LanguageServer should be marked ExcludeAssets="runtime".

[bettinaheim]

@ricardo-espinoza Could you take a look at this?

[ausbin]

I just tested and #1467 seems to resolve this. With the current Quantum SDK release (0.24.210930), I see the same behavior reported in dotnet/sdk#26065. But testing on the branch release/v0.25.2206 (which includes #1467 merged) by building the QsCompiler solution locally and using the <QscExe> setting in the project file and quantumDevKit.languageServerPath in my VSCode settings, I don't see the error spam in VSCode or when running dotnet build.

[baronfel]

That PR looks like it would resolve the issue for now, but I would expect it to come back again with other SDK version updates. In my opinion (and that of other MSBuild team members), the correct fix long term is to update your PackageReference with ExcludeAssets="runtime".

[ausbin]

Thanks for that suggestion, @baronfel. Could you share what that means to folks such as me who aren't msbuild gods? (That is, what does setting that option do?)

[bettinaheim]

@ricardo-espinoza I double checked and saw an NuGet.ProjectModel dependency doesn't seem to have the exclude. Could you please update this and confirm the functionality? Thanks

[baronfel]

This is the fun stuff :D The reference for 'dependency assets' in general is here, and for this scenario, we're mainly interested in two kinds of dependency asset:

• compile - assets from a package used during compilation. these might be ref assemblies or full assemblies for example.
• runtime - assets from a package used during actual execution. these are copied to the .deps.json file for your project and the CoreCLR will use this file to load them

When you add a PackageReference, by default you're setting a few properties that control how the assets in that package are used:

• IncludeAssets - assets that are used. this defaults to all, meaning everything
• ExcludeAssets - assets that are skipped/not used. this defaults to none, meaning skip nothing
• PrivateAssets - assets that should stay local to this project and not influence any projects that consume this project. this defaults to things like contentFiles, analyzers, MSBuild props/targets, etc.

When you add a PackageReference, you're saying 'include everything from this package' by default. This means that you'll compile against the package, and require its runtime dlls in order to execute. This is what's happening now with your (implicit or explicit) Nuget dependency. You're compiling against version X, but then at runtime, when MSBuild runs to evaluate a project, you're trying to load a different version of Nuget dependencies than you compiled against - the ones that were bundled in the SDK.

For apps that operate almost on a plugin model, where some external host dictates the versions of dependencies, we want to use the following semantics: 'compile against a known, potentially lower version of dependency X, but don't include any of the runtime assets for X because my hosting/execution environment will provide the actual DLL'. The way you express this in PackageReference form is through the ExcludeAssets="runtime" form - telling NuGet restore to not include the runtime assets of that dependency in your application.

This is what we tell MSBuild Task authors to do, too - because their task will operate entirely inside an MSBuild context, they should mark their MSBuild PackageReference in this way. Your situation is just one step further - because the .NET SDK also includes the same dependency on NuGet that you're trying to use in your library.

Does that help?

[filipw]

FWIW what we did to address the same problem in OmniSharp, is we delete Nuget.* libraries from the release build prior to packaging https://github.com/OmniSharp/omnisharp-roslyn/blob/master/build.cake#L599-L603 and then simply let them be loaded from the discovered SDK

[anpaz]

@baronfel,
Thanks for the pointers. We have incorporated the ExcludeAssets="runtime" to the Nuget.Frameworks on the LanguageServer project in #1462.
The good news is that indeed the dlls are not copied to the output folder and the language server loads correctly.
The bad news is that the tests are failing. Turns out MSTest has also its dependency on Nuget.Frameworks (see microsoft/vstest#3154). Applying the ExcludeAssets=runtime does not work and just prevents the tests to run all together. If ExcludeAssets is not included, the LanguageServer fails to load the dll. It's unclear to me how we can proceed. Any other suggestions?