Workspace failed with could not load "NuGet.Frameworks" error

[WeihanLi]

Version Used: 4.2.0

Steps to Reproduce:

There's a sample: https://github.com/WeihanLi/dotnet-exec/blob/c856424abe605ada9f4d2bedb68c3526d1241bc8/src/dotnet-exec/AdvancedCodeCompiler.cs

Expected Behavior:

Should work without error

Actual Behavior:

Failure, Msbuild failed when processing the file 'C:\projects\sources\SamplesInPractice\net7Sample\Net7Sample\Net7Sample.csproj' with message: C:\Program Files\dotnet\sdk\7.0.100-preview.4.22252.9\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets: (90, 5): The "ProcessFrameworkReferences" task failed unexpectedly.
      System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.3.0.32, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (0x80131621)
      File name: 'NuGet.Frameworks, Version=6.3.0.32, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
       ---> System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.3.0.32, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
         at System.Runtime.Loader.AssemblyLoadContext.<LoadFromPath>g____PInvoke__|5_0(IntPtr ptrNativeAssemblyBinder, UInt16* ilPath, UInt16* niPath, ObjectHandleOnStack retAssembly)
         at System.Runtime.Loader.AssemblyLoadContext.LoadFromPath(IntPtr ptrNativeAssemblyBinder, String ilPath, String niPath, ObjectHandleOnStack retAssembly)
         at System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(String assemblyPath)
         at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName)
         at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)
         at Microsoft.NET.Build.Tasks.ProcessFrameworkReferences.ExecuteCore()
         at Microsoft.NET.Build.Tasks.TaskBase.Execute()
         at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
         at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)

And I could not find the NuGet.Frameworks package with version 6.3.0 on the NuGet website, I finally find it in the sdk folder, did I miss some config?

[tmat]

@jasonmalinowski

[jasonmalinowski]

The customer's sample code looks right, at least at first glance. I've reached out to the MSBuild team for advice here.

[WeihanLi]

Hi @jasonmalinowski , any update on this? And should I move this to the MSBuild issues?

[jasonmalinowski]

@WeihanLi Ah thanks for the ping -- my back and forth with that team got lost in everything else going on. Just to confirm, what version of the SDK are you using?

[WeihanLi]

@jasonmalinowski thanks for your reply, I'm using the latest .NET 7 Preview 4/5/6/7 && RC SDK

[WeihanLi]

It may relate to

• NuGet version conflicts microsoft/MSBuildLocator#127
• Unable to load projects on .NET SDK 6.0.301 due to NuGet.Frameworks load errors microsoft/qsharp-compiler#1470

[carlossanlop]

@jasonmalinowski @rainersigwald I think I'm hitting this same issue in dotnet/api-docs-sync: dotnet/api-docs-sync#124

The code I'm fixing in that PR is for the PortToTripleSlash tool. It lets us backport documentation from dotnet-api-docs into triple slash comments in source.

I was able to get it to work when executed manually, no issues detected. But when I attempt to run the unit tests, I hit a very similar error as the one reported here:

Project.OpenProjectAsync - C:\Users\carlos\AppData\Local\Temp\dmeyjbwb.vtc\Project\MyAssembly.csproj

Failure - Msbuild failed when processing the file 'C:\Users\carlos\AppData\Local\Temp\dmeyjbwb.vtc\Project\MyAssembly.csproj' with message: C:\Program Files\dotnet\sdk\6.0.302\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.FrameworkReferenceResolution.targets: (90, 5): The "ProcessFrameworkReferences" task failed unexpectedly.
System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.2.1.7, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.Could not find or load a specific file. (0x80131621)
File name: 'NuGet.Frameworks, Version=6.2.1.7, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

Here is what the tests do:

• The test assets include a csproj file (MyAssembly.csproj) and two *.cs files. They are all copied to a temp folder.
• Then the test loads the VS instances using MSBuildLocator. All good here.
• Then in a separate context (to avoid running into the problem described here), the test creates a MSBuildWorkspace instance (all good here).
• But then, it tries to retrieve the project using workspace.OpenProjectAsync, and this is where the error shows up.

Ping me via Teams if you'd like to see a live repro. The tests are also able to generate a binlog, if you'd like to see it.

[JoeRobich]

The Microsoft.TestPlatform.ObjectModel used by the .NET Test SDK brings in an older version of NuGet than what is used by the .NET SDK. Roslyn misattributes this reference to the Microsoft.CodeAnalysis.Analyzer.Testing package in our version.props file.

roslyn/eng/Versions.props

Lines 210 to 215 in 2c86eb9

	<!--
	The package "Microsoft.CodeAnalysis.Analyzer.Testing" brings in an earlier version of these NuGet dependencies than
	is expected by the NET SDK used in the Workspace.MSBuild UnitTests. In order to test against the same verion of NuGet
	as our configured SDK, we must set the version to be the same.
	-->
	<NuGetCommonVersion>6.3.0-preview.2.73</NuGetCommonVersion>

For the purpose of running Unit Tests both dotnet-format and Roslyn add NuGet package references to their UnitTests and keep the NuGet version in step with the version of the .NET SDK pinned by our global.json.

See more details from this issue #52954 (comment)

cc: @nohwnd, @shyamnamboodiripad, @vritant24

I wonder if the SDK could just fix this up for us by adding implicit NuGet references which match the SDK version to UnitTest projects.

[nohwnd]

I think we should get rid of dependency on Nuget.Frameworks altogether if possible. We have quite limited range of supported frameworks and changes in how nuget.frameworks interprets versions has bitten us few times in the past.

[carlossanlop]

Thank you, @JoeRobich ! Your suggestion unblocked my problem with the tests.

Edit: Nevermind, it seems to be still there.

[MelnikovIG]

@carlossanlop Hello, i have almost same case as you, that start failing after latest sdk update. What exactly you did to fix this issue?

[carlossanlop]

@JoeRobich not sure exactly what happened, but I had to sync my clone to the latest bits, and then do a git clean -fdx. I ran the tests again after building, and the failure showed up one more time. Can I share a binlog with you?

[JoeRobich]

I ran the tests again after building, and the failure showed up one more time.

@carlossanlop I should have noted that the version number in my example above is only for .NET 7 SDK Preview 5. If you have installed the newer Preview 6 SDK, then we would need to find the matching NuGet version.

Can I share a binlog with you?

Sure thing.

[MelnikovIG]

@JoeRobich @carlossanlop Hey, i found workaround, that force roslyn to use sdk's dll version. There is not so good solution, but it works. In my case i got error after updating sdk to 6.0.302, where NuGet.Frameworks 6.2.1.7 is used, that is not exist in nuget, latest nuget version is 6.2.1.2. So i forced to copy sdk's version of dll to output directory.

  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <Copy SourceFiles="$(MSBuildSDKsPath)\..\NuGet.Frameworks.dll"
          DestinationFolder="$(OutputPath)"
          ContinueOnError="false" />
  </Target>

[WeihanLi]

None of above working for my case 😭

[craigktreasure]

Thanks @MelnikovIG! Your suggestion was clever and a good workaround that works for now.

I keep getting broken by this every now and then. It's quite obnoxious. Would love to see it fixed and prevented in the future.

[carlossanlop]

Yes, that worked! I now get the exact same behavior in both dotnet test and Test Explorer. Thank you for the universal workaround, @rainersigwald.

[csaba-sagi-sonarsource]

I am facing the same issue with v7.0.4 SDK, I see it was "fixed" in this PR.
@jasonmalinowski is there some ETA for when it is going to be released?

I tried to come over this problem by adding the following snippet to the .csproj I am trying to load (suggested workaround):

  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
    <Copy SourceFiles="$([System.IO.Directory]::GetParent($(BundledRuntimeIdentifierGraphFile)))\NuGet.Frameworks.dll"
          DestinationFolder="$(OutputPath)"
          ContinueOnError="false" />
    <Copy SourceFiles="$([System.IO.Directory]::GetParent($(BundledRuntimeIdentifierGraphFile)))\NuGet.Versioning.dll"
          DestinationFolder="$(OutputPath)"
          ContinueOnError="false" />
  </Target>

Indeed it made it possible to open the project with OpenProjectAsync without any issues, however when I try to compile the opened project with GetCompilationAsync, the compilation is not successful.
The project contains .razor files and it seems to me that the razor source generator is not run, since the compilation does not contain the syntax trees for the generated files.
I am not sure if this problem can be actually the root cause of why the source generators did not run. It would be nice to get this one fixed, so I can investigate further and see if there is another problem or if the two are related.

BTW, reverting to v7.0.3 will make both opening and compiling the project work.

[jasonmalinowski]

@csaba-sagi-sonarsource That fix applies to the language service executable for VS Code that we also build in this repo. Fixing it properly is still a bit more work to properly isolate all the versioning.

I am not sure if this problem can be actually the root cause of why the source generators did not run. It would be nice to get this one fixed, so I can investigate further and see if there is another problem or if the two are related.

This likely would be something else. Now that you mention it I wonder if we have a general hole here with Razor: Razor might be detecting that we're "in" a design time build and thus it thinks we're in an IDE, and as a result might disable the generator. There's some hacks here for how Visual Studio works and it might be tripping things up. Can you file a separate bug and we'll take a look?

[csaba-sagi-sonarsource]

I have opened this issue in the razor repository, with a bit more detail on what happens. If you need any further information on the problem, I am happy to help.

[jasonmalinowski]

So with the #70469, we now have MSBuildWorkspace running all builds in a separate process which will be isolated from your application dependencies. So dependencies on things like NuGet.Frameworks we no longer expect to be an issue.

[WeihanLi]

thanks very much @jasonmalinowski , and which version could be expected with this change?

[jasonmalinowski]

I would expect 4.9.0-2.final for the first preview bits.