[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)
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.
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
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.
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.
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>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
OSOE-49: Enforce Windows newlines for C# files to avoid false positives with IDE0055 warning.
Lombiq/.NET-Analyzers#55
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.
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.
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.
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.
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.
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.
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>
