roslyn icon indicating copy to clipboard operation
roslyn copied to clipboard

Published 20 hours ago • verified publisher icon dotnet

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

Open WeihanLi opened this issue 2 years ago • 16 comments

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?

WeihanLi avatar May 23 '22 00:05 WeihanLi

@jasonmalinowski

tmat avatar May 25 '22 19:05 tmat

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

jasonmalinowski avatar May 25 '22 23:05 jasonmalinowski

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

WeihanLi avatar Jun 26 '22 10:06 WeihanLi

@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?

jasonmalinowski avatar Jun 27 '22 22:06 jasonmalinowski

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

WeihanLi avatar Jun 28 '22 04:06 WeihanLi

It may relate to

  • https://github.com/microsoft/MSBuildLocator/issues/127
  • https://github.com/microsoft/qsharp-compiler/issues/1470

WeihanLi avatar Jul 05 '22 14:07 WeihanLi

@jasonmalinowski @rainersigwald I think I'm hitting this same issue in dotnet/api-docs-sync: https://github.com/dotnet/api-docs-sync/pull/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.

carlossanlop avatar Jul 16 '22 21:07 carlossanlop

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.

https://github.com/dotnet/roslyn/blob/2c86eb91e511971fcf721f53a6efa4fdac4a57b6/eng/Versions.props#L210-L215

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 https://github.com/dotnet/roslyn/issues/52954#issuecomment-880315898

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.

JoeRobich avatar Jul 18 '22 20:07 JoeRobich

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.

nohwnd avatar Jul 19 '22 10:07 nohwnd

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

Edit: Nevermind, it seems to be still there.

carlossanlop avatar Jul 19 '22 19:07 carlossanlop

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

MelnikovIG avatar Jul 20 '22 15:07 MelnikovIG

@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?

carlossanlop avatar Jul 20 '22 16:07 carlossanlop

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.

JoeRobich avatar Jul 20 '22 16:07 JoeRobich

@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>

MelnikovIG avatar Jul 21 '22 08:07 MelnikovIG

None of above working for my case 😭

WeihanLi avatar Jul 22 '22 17:07 WeihanLi

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.

craigktreasure avatar Aug 06 '22 05:08 craigktreasure

@MelnikovIG thank you for the workaround. That did the trick for me. Here's confirmation:

Before workaround: Tests could not run properly 
dotnet test
  Determining projects to restore...
  All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(257,5): message NET
SDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy [D:\api-docs-sync\src\PortToTripleSlash\tests\tests.cspro
j]
C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(257,5): message NET
SDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy [D:\api-docs-sync\src\PortToTripleSlash\src\libraries\lib
raries.csproj]
  libraries -> D:\api-docs-sync\src\PortToTripleSlash\src\libraries\bin\Debug\net7.0\libraries.dll
  tests -> D:\api-docs-sync\src\PortToTripleSlash\tests\bin\Debug\net7.0\tests.dll
Test run for D:\api-docs-sync\src\PortToTripleSlash\tests\bin\Debug\net7.0\tests.dll (.NETCoreApp,Version=v7.0)
Microsoft (R) Test Execution Command Line Tool Version 17.4.0 (x64)
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:06.43]     ApiDocsSync.Libraries.Tests.PortToTripleSlashTests.Port_Generics [FAIL]
  Failed ApiDocsSync.Libraries.Tests.PortToTripleSlashTests.Port_Generics [2 s]
  Error Message:
   System.Exception :
Project.OpenProjectAsync - C:\Users\carlos\AppData\Local\Temp\ylmpdpz5.iyz\Project\MyAssembly.csproj
    Failure - Msbuild failed when processing the file 'C:\Users\carlos\AppData\Local\Temp\ylmpdpz5.iyz\Project\MyAssembly.csproj' with message: C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\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.4.0.94, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (0x80131621)
File name: 'NuGet.Frameworks, Version=6.4.0.94, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
 ---> System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.4.0.94, 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.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)
  Stack Trace:
     at ApiDocsSync.Libraries.MSBuildLoader.ThrowIfDiagnosticsFound(ResolvedWorkspace resolvedWorkspace, String origin, Boolean isMono) in D:\api-docs-sync\src\PortToTripleSlash\src\libraries\MSBuildLoader.cs:line 176
   at ApiDocsSync.Libraries.MSBuildLoader.LoadProjectAsync(String projectPath, Boolean isMono, CancellationToken cancellationToken) in D:\api-docs-sync\src\PortToTripleSlash\src\libraries\MSBuildLoader.cs:line 82
   at ApiDocsSync.Libraries.MSBuildLoader.LoadMainProjectAsync(String projectPath, Boolean isMono, CancellationToken cancellationToken) in D:\api-docs-sync\src\PortToTripleSlash\src\libraries\MSBuildLoader.cs:line 63
   at ApiDocsSync.Libraries.Tests.PortToTripleSlashTests.PortToTripleSlashAsync(String testDataDir, Boolean skipInterfaceImplementations, String assemblyName, String namespaceName) in D:\api-docs-sync\src\PortToTripleSlash\tests\PortToTripleSlash\PortToTripleSlashTests.cs:line 66
--- End of stack trace from previous location ---
[xUnit.net 00:00:07.06]     ApiDocsSync.Libraries.Tests.PortToTripleSlashTests.Port_Basic [FAIL]
  Failed ApiDocsSync.Libraries.Tests.PortToTripleSlashTests.Port_Basic [635 ms]
  Error Message:
   System.Exception :
Project.OpenProjectAsync - C:\Users\carlos\AppData\Local\Temp\y1dnabm0.ijy\Project\MyAssembly.csproj
    Failure - Msbuild failed when processing the file 'C:\Users\carlos\AppData\Local\Temp\y1dnabm0.ijy\Project\MyAssembly.csproj' with message: C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\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.4.0.94, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Could not find or load a specific file. (0x80131621)
File name: 'NuGet.Frameworks, Version=6.4.0.94, Culture=neutral, PublicKeyToken=31bf3856ad364e35'
 ---> System.IO.FileLoadException: Could not load file or assembly 'NuGet.Frameworks, Version=6.4.0.94, 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.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)
  Stack Trace:
     at ApiDocsSync.Libraries.MSBuildLoader.ThrowIfDiagnosticsFound(ResolvedWorkspace resolvedWorkspace, String origin, Boolean isMono) in D:\api-docs-sync\src\PortToTripleSlash\src\libraries\MSBuildLoader.cs:line 176
   at ApiDocsSync.Libraries.MSBuildLoader.LoadProjectAsync(String projectPath, Boolean isMono, CancellationToken cancellationToken) in D:\api-docs-sync\src\PortToTripleSlash\src\libraries\MSBuildLoader.cs:line 82
   at ApiDocsSync.Libraries.MSBuildLoader.LoadMainProjectAsync(String projectPath, Boolean isMono, CancellationToken cancellationToken) in D:\api-docs-sync\src\PortToTripleSlash\src\libraries\MSBuildLoader.cs:line 63
   at ApiDocsSync.Libraries.Tests.PortToTripleSlashTests.PortToTripleSlashAsync(String testDataDir, Boolean skipInterfaceImplementations, String assemblyName, String namespaceName) in D:\api-docs-sync\src\PortToTripleSlash\tests\PortToTripleSlash\PortToTripleSlashTests.cs:line 66
--- End of stack trace from previous location ---

Failed!  - Failed:     2, Passed:     0, Skipped:     0, Total:     2, Duration: 634 ms - tests.dll (net7.0)
After workaround: The error is gone, now I can fix other failures 
dotnet test
  Determining projects to restore...
  All projects are up-to-date for restore.
C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(257,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/d
otnet-support-policy [D:\api-docs-sync\src\PortToTripleSlash\tests\tests.csproj]
C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(257,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/d
otnet-support-policy [D:\api-docs-sync\src\PortToTripleSlash\src\libraries\libraries.csproj]
  libraries -> D:\api-docs-sync\src\PortToTripleSlash\src\libraries\bin\Debug\net7.0\libraries.dll
  tests -> D:\api-docs-sync\src\PortToTripleSlash\tests\bin\Debug\net7.0\tests.dll
Test run for D:\api-docs-sync\src\PortToTripleSlash\tests\bin\Debug\net7.0\tests.dll (.NETCoreApp,Version=v7.0)
Microsoft (R) Test Execution Command Line Tool Version 17.4.0 (x64)
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:03.75]     ApiDocsSync.Libraries.Tests.PortToTripleSlashTests.Port_Basic [FAIL]
  Failed ApiDocsSync.Libraries.Tests.PortToTripleSlashTests.Port_Basic [711 ms]
  Error Message:
   System.Exception : <Errors unrelated to nuget/msbuild>
  Stack Trace:
    <Stacktrace...>
--- End of stack trace from previous location ---

Failed!  - Failed:     1, Passed:     1, Skipped:     0, Total:     2, Duration: 724 ms - tests.dll (net7.0)

carlossanlop avatar Oct 25 '22 20:10 carlossanlop

I have a question - Why is the value of $(MSBuildSDKsPath) different when running the unit tests using dotnet test, vs running the tests using the Test Explorer in Visual Studio?

With dotnet test, the tests run successfully because the path is located:

$(MSBuildSDKsPath) = C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\Sdks

But with Test Explorer, the test fails to find the Nuget.Frameworks.dll, because this is the value:

$(MSBuildSDKsPath) = C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Sdks

Error when attempting to run tests with Test Explorer:

MSB3030	Could not copy the file 
"C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Sdks\..\NuGet.Frameworks.dll" because it was not found.

carlossanlop avatar Oct 25 '22 20:10 carlossanlop

MSBuildSdksPath is a weird implementation detail that's generally a bit fragile to depend on. It means "where should MSBuild look for SDKs as a last resort after trying everywhere else?", and its default value is "in a folder named Sdks next to MSBuild". Since MSBuild can be either from VS or from the .NET SDK, that's not a super stable location (and DLLs resolved from either place may not work in the other/in a .NET 6 app).

rainersigwald avatar Oct 25 '22 21:10 rainersigwald

Maybe $([System.IO.Directory]::GetParent($(BundledRuntimeIdentifierGraphFile)))\NuGet.Frameworks.dll instead? It's ugly but should always point to the right place (at the moment, no guarantee in future SDKs that the relative paths between that file and the NuGet assemblies stay constant--but also they haven't changed in a while AFAIK).

rainersigwald avatar Oct 25 '22 21:10 rainersigwald

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

carlossanlop avatar Oct 25 '22 22:10 carlossanlop

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.

csaba-sagi-sonarsource avatar Aug 14 '23 15:08 csaba-sagi-sonarsource

@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?

jasonmalinowski avatar Aug 14 '23 17:08 jasonmalinowski

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.

csaba-sagi-sonarsource avatar Aug 15 '23 21:08 csaba-sagi-sonarsource

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.

jasonmalinowski avatar Nov 15 '23 20:11 jasonmalinowski

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

WeihanLi avatar Nov 16 '23 01:11 WeihanLi

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

jasonmalinowski avatar Nov 16 '23 01:11 jasonmalinowski