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

[pmalmsten]

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:

1. Follow these instructions for creating a Web App project from a template.
2. 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.
3. 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'

1. 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.

[dotnet-issue-labeler]

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.

[pmalmsten]

I updated the bug description with steps to reproduce.

[richardb355]

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).

[alexanderjung-sdxag]

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

[El-Gor-do]

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.

[lechgu]

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

[andyleejordan]

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)

[AndrewBabbitt97]

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

[Meligy]

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.

[Serg046]

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

[RobLSDev]

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.

[roldengarm]

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

[IvanKult]

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.

[andreybogdashyts]

have fixed it in VS Code by adding below settings

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

[Jothay]

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

Thank you @El-Gor-do

[deeprobin]

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.

[craigktreasure]

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

[AndrewBabbitt97]

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.

[zcsizmadia]

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.

[Piedone]

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>

[drauch]

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

[scugzbc]

upgrade from 17.0.0 to 17.1.4 also fixed it for me.

[andyleejordan]

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

[mkArtakMSFT]

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

[AraHaan]

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

[m12lrpv]

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

[AraHaan]

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.

[AB017JH]

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.

[AraHaan]

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.

[HuibertJan]

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

[Meligy]

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

[namra98]

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

[Mahdi-Shad]

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.

[mgroetan]

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.

[mgroetan]

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.

[AraHaan]

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

[richieto]

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.

[SMohsenM]

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>