.NET Core SDK 6.0.200: Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.1.0.0'

Question

.NET Core SDK 6.0.200: Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.1.0.0'

pmalmsten opened this issue 3 years ago · 40 comments

Describe the bug

Build fails with error:
##[error]CSC(0,0): Error CS8032: An instance of analyzer Microsoft.NET.Sdk.Razor.SourceGenerators.RazorSourceGenerator cannot be created from C:\hostedtoolcache\windows\dotnet\sdk\6.0.200\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.NET.Sdk.Razor.SourceGenerators.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified..
when using .NET Core SDK 6.0.200 with Visual Studio 2022 on Azure DevOps Microsoft-Hosted Agent.

Error goes away after reverting to .NET Core SDK 6.0.102.

I was unable to reproduce this on my personal Windows 11 machine using Visual Studio 2022 (with latest updates) and running a build command very similar to what Azure DevOps does: "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "C:\Users\paulmalmsten\source\repos\Terrapin\PackageRebuilder.sln" /nologo /nr:false -m /p:configuration="debug" /p:VisualStudioVersion="17.0" /p:_MSDeployUserAgent="VSTS_011b8bdf-6d56-4f87-be0d-0092136884d9_build_11835_0"

Azure DevOps image version where this was observed: https://github.com/actions/virtual-environments/releases/tag/win22%2F20220207.1

To Reproduce

I was able to reproduce this issue on a template Web App project created by Visual Studio 2022 without modification.

Steps:

Follow these instructions for creating a Web App project from a template.
Check the project into Git (in my example, under the WebApplication1 directory below the git repository root), push to a branch in Azure Dev Ops.
Configure an Azure DevOps Pipeline which runs on windows-2022 having the following steps:

- task: NuGetToolInstaller@1
  displayName: 'Install NuGet 6.x'
  inputs:
    versionSpec: 6.x

- task: UseDotNet@2
  displayName: 'Add .NET 5.0'  
  inputs:
    packageType: 'sdk'
    version: '5.0.x'

- task: UseDotNet@2
  displayName: 'Add .NET 6.0'  
  inputs:
    packageType: 'sdk'
    version: '6.0.x'

- task: NuGetCommand@2
  displayName: 'NuGet Restore'
  inputs:
    restoreSolution: '$(Build.SourcesDirectory)\WebApplication1\WebApplication1.sln'

- task: VSBuild@1
  displayName: 'Build the solution'
  inputs:
    solution: '$(Build.SourcesDirectory)\WebApplication1\WebApplication1.sln'
    configuration: 'debug'
    msbuildArgs: '-m'

Run the Azure DevOps Pipeline.

Expected Result: Compiles successfully.
Actual result: Error message seen above.

Exceptions (if any)

Not applicable.

Further technical details

Include the output of dotnet --info

.NET SDK (reflecting any global.json):
 Version:   6.0.200
 Commit:    4c30de7899

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.20348
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\hostedtoolcache\windows\dotnet\sdk\6.0.200\

Host (useful for support):
  Version: 6.0.2
  Commit:  839cdfb0ec

.NET SDKs installed:
  5.0.405 [C:\hostedtoolcache\windows\dotnet\sdk]
  6.0.200 [C:\hostedtoolcache\windows\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.14 [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.2 [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 5.0.14 [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.2 [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.14 [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 6.0.2 [C:\hostedtoolcache\windows\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

Not applicable. Error happens on Azure DevOps hosted agent.

Answer 1 · 2022-02-16T20:38:22.000Z

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Answer 2 · 2022-02-16T21:02:26.000Z

I updated the bug description with steps to reproduce.

Answer 3 · 2022-02-16T22:10:12.000Z

We're also seeing this trying to build a .NET 6 Blazor app on a hosted agent using image 'windows-2022' (with image version '20220207.1'), and also using .NET SDK 6.0.200. It started happening as soon as the .NET SDK version moved to 6.0.200 (didn't happen on SDK 6.0.102).

Answer 4 · 2022-02-17T08:55:09.000Z

Same issue here. It happend on the build server, but not locally.

For those also affected: The workaround from pmalmsten works:

global.json:
{ "sdk": { "version": "6.0.100", "rollForward": "disable" } }

.yaml for the build pipelines:
task: UseDotNet@2 displayName: 'Use .NET Core SDK 6.0' inputs: packageType: sdk version: 6.0.100

HIH

Answer 5 · 2022-02-17T09:54:52.000Z

I had the same problem with CS8032 warnings when building in Visual Studio 2022 17.0.6 using SDK 6.0.200. After upgrading to Visual Studio 2022 17.1.0, the CS8032 warnings disappeared.

Answer 6 · 2022-02-17T20:50:59.000Z

same here, omnisharp in vscode is broken on 6.0.200 with this exception.

Answer 7 · 2022-02-19T00:48:44.000Z

Same here, I'd blown away all my dotnet installations and started with a clean 6.0.200 install and now OmniSharp won't give me any code fixes. I thought I'd broken something when I saw

[fail]: OmniSharp.MSBuild.ProjectManager
        Failure while loading the analyzer reference 'Microsoft.CodeAnalysis.CodeStyle': Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.

repeated in the logs, since the docs say the package is unnecessary for SDK-style projects targeting .NET 5 and above.

Seems like it's actually an OmniSharp issue as its release is lagging behind the SDK's release: dotnet/vscode-csharp#5061 (comment)

Answer 8 · 2022-02-19T06:15:04.000Z

This same issue is breaking dotnet-format: dotnet/format#1519

Answer 9 · 2022-02-19T07:18:11.000Z

This definitely seems to be the issue with dotnet format as mentioned in previous comment. It's also worth noting that adding Microsoft.CodeAnalysis as a package reference, even with PrivateAssets and all, does not seem to solve this problem.

It would be great if there's another workaround other than downgrading the SDK version. I discovered this as my enterprise client's self-hosted CI has just supported .NET 6, specifically .NET 6.0.200.

Answer 10 · 2022-02-19T12:14:29.000Z

Same issue with SDK 6.0.101 (the one installed on AppVeyor...)
https://ci.appveyor.com/project/Serg046/autofake/builds/42638396

Answer 11 · 2022-02-19T12:29:31.000Z

I'm having the same issue with builds directly on build agents in Azure DevOps, but building locally using VS 17.1.0 works fine. I suspect when they update VS Build Task and binaries on the build image it'll go away, but that probably doesn't help those using VS Code or other build environments.

Answer 12 · 2022-02-22T00:09:15.000Z

Same problem on ubuntu-latest, after banging my head against the wall as I didn't understand why my pipelines were suddenly failing I found this post.
So, lesson learnt, better to specify the exact SDK version to avoid upgrade problems like this.
Adding a global.json and a step to install that particular version fixed it, thanks @alexanderjung-sdxag

Answer 13 · 2022-02-22T13:00:09.000Z

This issue was fixed in OmniSharp v1.38.1 (2022-02-18) , but in VSCode Extension Marketplace latest available release is 1.24.0. Potentially latest omnisharp version can be installed manually from github build, but I hope, that latest release will be available for download in Marketplace soon.

Answer 14 · 2022-02-23T07:58:28.000Z

have fixed it in VS Code by adding below settings

"omnisharp.useModernNet": true, 
"omnisharp.path": "latest"

Answer 15 · 2022-03-01T19:47:30.000Z

VS2022 v17.0.5 was having this issue and upgrading to v17.1.0 fixed it.

Thank you @El-Gor-do

Answer 16 · 2022-03-04T16:03:59.000Z

VS2022 v17.0.5 was having this issue and upgrading to v17.1.0 fixed it.

Thank you @El-Gor-do

The upgrade from 17.0.0 to 17.1.0 also fixed it for me.
Seems to have been an issue on the part of Visual Studio (or the csc executable provided by VS), since I specified the SDK version (6.0.200) in my global.json.

I think this issue can be closed.

Answer 17 · 2022-03-04T17:45:58.000Z

I have 17.1.0 and am still hitting the issue. So I don't agree that it should be closed.

Answer 18 · 2022-03-04T20:54:26.000Z

This error can crop up on the CLI as well, it's not restricted to Visual Studio environments. So I agree with the above. Issue is not yet resolved.

Answer 19 · 2022-03-10T12:41:34.000Z

I use ./dotnet-install.sh --channel "6.0" in out travis image to install the 6.0 SDK. However that installs 6.0.103, which fails with the above errors. (wget https://dot.net/v1/dotnet-install.sh). For some reason curl https://dotnetcli.azureedge.net/dotnet/Sdk/6.0/latest.version return 6.0.103. Which IMO should be 6.0.201?

When I use ./dotnet-install.sh --version "6.0.201" to install the latest version, the errors are gone.

Answer 20 · 2022-03-11T01:24:35.000Z

A workaround is to add this to your csproj:

  <ItemGroup>
    <PackageReference Include="Microsoft.Net.Compilers.Toolset" Version="4.1.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers;</IncludeAssets>
    </PackageReference>
  </ItemGroup>

Answer 21 · 2022-03-11T04:07:07.000Z

A workaround is to add this to your csproj:

  <ItemGroup>
    <PackageReference Include="Microsoft.Net.Compilers.Toolset" Version="4.1.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers;</IncludeAssets>
    </PackageReference>
  </ItemGroup>

Dang. I got excited. But, that didn't work for me.

Answer 22 · 2022-03-24T14:28:55.000Z

I have this issue on an M1 iMac (fully updated) with VS 2022 Preview 7.

Answer 23 · 2022-03-24T14:37:33.000Z

I also experience this problem with the VS 2022 and SDK 6.0.201, updating to the latest version helped me though.

Answer 24 · 2022-04-13T14:22:46.000Z

upgrade from 17.0.0 to 17.1.4 also fixed it for me.

Answer 25 · 2022-04-13T16:45:55.000Z

I confirmed that the dotnet CLI upgrade to SDK 6.0.202 has fixed this.

Answer 26 · 2022-04-18T16:51:58.000Z

Closing as this seem to be fixed already. Thanks for confirmation, @andschwa

Answer 27 · 2022-05-07T17:20:19.000Z

I am experiencing this issue locally but with it not being able to load 4.3.0.0 of this assembly inside of VS2022 17.2 Preview 6 with an build of the .NET SDK Preview 5 installed (7.0.100-preview.5.22229.2).

cc: @mkArtakMSFT

Answer 28 · 2022-05-18T23:53:10.000Z

This is definitely not fixed. Upgrading to 6.0.20+ just changes the error.

Answer 29 · 2022-05-19T01:31:44.000Z

For me, what worked was using the daily builds of the .NET 7 SDK and then manually switching it's analyzers to the latest stable releases of all of it's analyzers (except the source generators) and it ended up working fine after that.

This is because the daily .NET 7 builds uses roslyn 4.3.0 preview builds.

Answer 30 · 2022-05-20T12:18:32.000Z

I hit this as well. When running from VS 17.2.1 with sdk 6.0.3, some of the NuGet packages do not get copied, when running dotnet build with global.json with 6.0.101 works.

Answer 31 · 2022-05-20T20:25:37.000Z

Cant another workaround for the compiler libraries in the IDE is to install an local build of them into the IDE (and then keep it up to date with their branch main)?

It might possibly be risky but I think it could be another option as well.

Answer 32 · 2022-10-11T09:12:48.000Z

For those that are coming here and looking for answers:

I could fix it by upgrading visual studio to 17.3.5 from 17.2.5

Answer 33 · 2022-10-12T13:15:35.000Z

The exact upgrade that's needed is for the .NET SDK to be 6.0.202 or higher.

Answer 34 · 2023-05-24T08:50:24.000Z

Hitting same issue with .NET SDK 6.0.400 and 6.0.408.
This is definitely not fixed yet!

Answer 35 · 2023-06-09T10:00:29.000Z

I have the same issue with Visual Studio 2022 Version 17.6.2 just for my project with target framework net6.0 :
Error CS8032 An instance of analyzer Microsoft.NET.Sdk.Razor.SourceGenerators.RazorSourceGenerator cannot be created from C:\Program Files\dotnet\sdk\7.0.302\Sdks\Microsoft.NET.Sdk.Razor\source-generators\Microsoft.NET.Sdk.Razor.SourceGenerators.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.

I have both dotnet 6.0.408, and 7.0.302 on my machine.

Answer 36 · 2023-08-09T15:39:55.000Z

Don't know if this helps any future readers at all, but a long time ago we installed the "Microsoft.CodeAnalysis.Compilers" and "Microsoft.Net.Compilers.Toolset" NuGet packages, as per the advice given in https://stackoverflow.com/a/71208208.
That immediately resolved the problem, and has worked flawlessly since.

Then it broke again, with the same symptom of the web log showing that views couldn't be found (they were not embedded any more).
What triggered it this time seems to be that we centralized our code analyzer handling. Using the StyleCop NuGet package, we had previously had to reference that in every single project, as well as point to its config file.
Now we removed all of that, and placed the StyleCop NuGet package reference in the root "Directory.Build.props" file instead, with these additional new properties:

<EnableNETAnalyzers>true</EnableNETAnalyzers>
<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>

Building the project in Azure DevOps then yielded a bus load of build warnings like this:

##[warning]CSC(0,0): Warning CS9057: The analyzer assembly 'C:\hostedtoolcache\windows\dotnet\sdk\7.0.400\Sdks\Microsoft.NET.Sdk\codestyle\cs\
Microsoft.CodeAnalysis.CodeStyle.dll' references version '4.7.0.0' of the compiler, which is newer than the currently running version '4.6.0.0'.

We were using the 4.6.0 version of those two NuGet packages.

We then followed the advice of the updated answer of the aforementioned SO issue, that suggested to now remove those two NuGet packages again, as well as adding the following:
<FrameworkReference Include="Microsoft.AspNetCore.App" />

After removing the two NuGet packages, our runtime problems disappeared, so something has been fixed somewhere, not requiring these packages to be referenced any more (which could only be a good thing, judging by the rather scary description of the "Microsoft.Net.Compilers.Toolset" NuGet package - go and look it up for fun...).

We did NOT follow the advice of adding the framework reference, though, as that yields a build warning of its own:

Warning	NETSDK1086	A FrameworkReference for 'Microsoft.AspNetCore.App' was included in the project. 
This is implicitly referenced by the .NET SDK and you do not typically need to reference it from your project. 
For more information, see https://aka.ms/sdkimplicitrefs

That reference was nonetheless already visible in Visual Studio 2022's solution explorer, under "Dependencies | Frameworks" for the web project in question.

Answer 37 · 2023-08-14T08:54:54.000Z

An update to my previous findings related to removing the two "Microsoft.CodeAnalysis.Compilers" and "Microsoft.Net.Compilers.Toolset" NuGet packages;
This worked flawlessly in one Azure DevOps build pipeline, but we later discovered that it was indeed failing the original way in another. That is, with the symptom of not embedding the ASP.NET MVC Core views in the assembly.

That led me to look at which tools were actually used to build in those two cases.
The one that worked used a manual "dotnet publish" command in a Dockerfile (with implicit "dotnet build"), using the .NET SDK version 7.0.400. To actually build, it uses its bundled MSBuild version 17.7.1.

The one that didn't work, on the other hand, was using the "Visual Studio build" task available to Azure DevOps pipelines.
It was configured to use the "Latest" version of Visual Studio, i.e. 2022, effectively getting the 17.6.6 version.
Once more, to actually build, it also uses its bundled MSBuild, but this time a fairly older 17.6.3 version.

So, to conclude, the MSbuild tool actually seems to be the problem here, and you will need to use a new enough version of it.
Why the latest VS would remain so far behind the latest available MSBuild is a mystery to me.

Answer 38 · 2023-08-14T11:08:48.000Z

Even better, build msbuild and all the tools you need yourself for the absolute latest version.

Answer 39 · 2023-09-05T13:29:02.000Z

We experienced the same problems, for us, it started happening once the runner-images on the Azure pipeline agents were updated in August. We had several problems as we had NET 6 and NET 7 versions running side by side in different environments.

As pointed out by @mgroetan the main problem is the combination of which version of MSBuild is used, the csproj configuration and the SDK.

For NET 6 (using the SDK 6.0.410-413)
The latest runner-image of Azure pipeline agents started using MSBuild version 17.7.1 and that broke our environment with our NET 6 solution. Here a simple downgrade to use the windows-2019 agent was enough for the agent to use MSBuild version 17.6.3 and keep embedding the views. We did not investigate on this anymore as this is a deprecated version for us.

For NET 7 (using the SDK 7.0.305)
Oddly enough, the runner-image of the Azure pipeline agents was using MSBuild version 17.6.3 to build the solution, and therefore managed to embed the views even though we had the "Microsoft.Net.Compilers.Toolset" NuGet packages.
Locally this started failing with MSBuild version 17.7.1. So we did the following:

Removed the "Microsoft.Net.Compilers.Toolset" NuGet packages.
Moved to:
<EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild>
Started using SDK 7.0.400 (latest at the time of writing)

Now Things are looking good again.

Answer 40 · 2023-10-19T16:33:54.000Z

I had the same issue when upgrading from SDK version 7.0.307 to SDK version 7.0.402. After upgrading, all views are missing in the DLL by building the project.
Adding Microsoft.Net.Compilers.Toolset fixes my problem.

    <PackageReference Include="Microsoft.Net.Compilers.Toolset" Version="4.7.0">
      <PrivateAssets>all</PrivateAssets>
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
    </PackageReference>