Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loading net5.0 Assemblies Shouldn't Happen When Running < net5.0 #92

Closed
benvillalobos opened this issue Aug 18, 2020 · 3 comments · Fixed by #106
Closed

Loading net5.0 Assemblies Shouldn't Happen When Running < net5.0 #92

benvillalobos opened this issue Aug 18, 2020 · 3 comments · Fixed by #106

Comments

@benvillalobos
Copy link
Member

Related issue and repro: dotnet/msbuild#5600

When targeting netcore3.1 and loading an assembly that depends on a net5.0 assembly (in this case Microsoft.Build.NuGetSdkResolver depending on System.Runtime version 5.0), it can fail to load.

It fails on line 118 of SdkResolverService

                 result = (SdkResult)sdkResolver.Resolve(sdk, context, resultFactory);
"System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
File name: 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at Microsoft.Build.NuGetSdkResolver.NuGetSdkResolver.Resolve(SdkReference sdkReference, SdkResolverContext resolverContext, SdkResultFactory factory)
   at Microsoft.Build.BackEnd.SdkResolution.SdkResolverService.ResolveSdk(Int32 submissionId, SdkReference sdk, LoggingContext loggingContext, ElementLocation sdkReferenceLocation, String solutionPath, String projectPath, Boolean interactive)

"

We should consider changing MSBuildLocator to NOT return .NET Core SDK's that are newer than the current .NET Core runtime.

@jzabroski
Copy link

Innocent question: How would you know, in general, the current .NET Core runtime version is "less than" a particular installed version? What logic do you suggest? What about if .NET Core adopts an Android-style API levels concept? That is what net472 and netstandard2.0 tried, but it was an utter failure for OOB scenarios. Maybe this will work for In-Box scenarios since Microsoft can create a closed world where the "less than" operator is statically known and can fully regression test the SdkReference universe because its known via double secret handshake. But you can't extend this to plug-ins that use a PackageReference, right?

@AArnott
Copy link
Member

AArnott commented Nov 4, 2020

This is breaking our dotnet mpc tool: MessagePack-CSharp/MessagePack-CSharp#1102

@viktorveis
Copy link
Member

This issue is breaking the Q# language server if .NET 5.0 is installed: microsoft/qsharp-compiler#737

Forgind added a commit that referenced this issue Dec 17, 2020
Components of the SDK often have dependencies on the runtime they shipped with, including that several tasks that shipped in the .NET 5 SDK rely on the .NET 5.0 runtime. Assuming the runtime that shipped with a particular SDK has the same version, this ensures that we don't choose an SDK that doesn't work with the runtime of the chosen application. This is not guaranteed to always work but should work for now.

Fixes #92

This is based on #79.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants