The analyzer assembly references version '4.6.0.0' of the compiler, which is newer than the currently running version '4.5.0.0'

[RussKie]

I'm working on a non-public project. I can provide a repro and/or binlog via Teams.

Having moved to the latest .NET SDK from:

{
  "sdk": {
    "version": "8.0.100-alpha.1.23061.8"
  },
  "tools": {
    "dotnet": "8.0.100-alpha.1.23061.8"
  }
}

...to

{
  "sdk": {
    "version": "8.0.100-preview.2.23115.11"
  },
  "tools": {
    "dotnet": "8.0.100-preview.2.23115.11"
  }
}

I'm no longer able to build:

Build FAILED.

CSC : error CS9057: The analyzer assembly 'D:\Dev\test\.dotnet\sdk\8.0.100-preview.2.23115.11\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CodeStyle.dll' references version '4.6.0.0' of the comp 
iler, which is newer than the currently running version '4.5.0.0'. [D:\Dev\test\src\Analyzers\Roslyn4.0\Analyzers.Roslyn4.0.csproj]
CSC : error CS9057: The analyzer assembly 'D:\Dev\test\.dotnet\sdk\8.0.100-preview.2.23115.11\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CSharp.CodeStyle.dll' references version '4.6.0.0' of t 
he compiler, which is newer than the currently running version '4.5.0.0'. [D:\Dev\test\src\Analyzers\Roslyn4.0\Analyzers.Roslyn4.0.csproj]
    0 Warning(s)
    2 Error(s)

Welp? :)

[RussKie]

Looks like our repo had Microsoft.Net.Compilers.Toolset pinned to 4.5.0. Bumping that to 4.6.* version appears to have resolved the issue. However, this would remain a real head scratcher if it wasn't for a colleague - the error message isn't very descriptive and there are no obvious dependencies between Microsoft.Net.Compilers.Toolset and Microsoft.CodeAnalysis.CodeStyle:

[Youssef1313]

The fact that analyzer assemblies require a minimum required compiler version is by-design.

Not sure if it is possible to detect that the compiler is referenced from Microsoft.Net.Compilers.Toolset and then produce a customized message?

I guess we can add a property to Microsoft.Net.Compilers.Toolset.props like <IsCompilersToolsetPackageReferenced>true</IsCompilersToolsetPackageReferenced> and pass this value to CoreCompile target then pass down to Csc?

[RussKie]

The fact that analyzer assemblies require a minimum required compiler version is by-design.

I don't disagree here. I'm new to the codebase I'm working on, and the error message wasn't really helpful.

[jasonmalinowski]

Not sure if it is possible to detect that the compiler is referenced from Microsoft.Net.Compilers.Toolset and then produce a customized message?

Possibly. @RussKie Any idea why you have that reference to Microsoft.Net.Compilers.Toolset in the first place?

(tagging @jaredpar and @tmat, who was recently trying to understand scenarios where folks are doing this)

[Youssef1313]

(tagging @jaredpar and @tmat, who was recently trying to understand scenarios where folks are doing this)

A scenario I know of is building against different versions of the .NET SDK (6 and 7), and we want to use the same version of the compiler, so we use Microsoft.Net.Compilers.Toolset

Another scenario I can think of is faster adoption of new versions.

[tmat]

A scenario I know of is building against different versions of the .NET SDK (6 and 7), and we want to use the same version of the compiler, so we use Microsoft.Net.Compilers.Toolset

What does it mean "building against different versions of the .NET SDK"? Wouldn't multi-targeting the project to net6.0 and net7.0 do (while using a single SDK 7.0 and the compiler that ships with it)?

Another scenario I can think of is faster adoption of new versions.

Why doesn't setting the SDK version in global.json and using the compiler from that SDK achieve that?

[Youssef1313]

A scenario I know of is building against different versions of the .NET SDK (6 and 7), and we want to use the same version of the compiler, so we use Microsoft.Net.Compilers.Toolset

What does it mean "building against different versions of the .NET SDK"? Wouldn't multi-targeting the project to net6.0 and net7.0 do (while using a single SDK 7.0 and the compiler that ships with it)?

Another scenario I can think of is faster adoption of new versions.

Why doesn't setting the SDK version in global.json and using the compiler from that SDK achieve that?

In the general case, yes, multi-targeting with .NET 7 SDK should work. But there is dotnet/sdk#30103 that prevents that from happening.

---

Why doesn't setting the SDK version in global.json and using the compiler from that SDK achieve that?

Sometimes the NuGet package ships faster than the .NET SDK.

[tmat]

Sometimes the NuGet package ships faster than the .NET SDK.

I'd consider that super niche scenario though that we do not support. It might mean some IDE features are broken.

[jasonmalinowski]

Sometimes the NuGet package ships faster than the .NET SDK.

There's also a general risk that if you move newer at one point, you then forgot you updated that and a few years later you're still using a pinned old version, and you don't realize that. That can result in general issues too as we move targets forward and such. We often find ourselves with customers complaining about bugs we already fixed, only to realize they had pinned their compiler version sometime in the past and then forgot.

[RussKie]

Any idea why you have that reference to Microsoft.Net.Compilers.Toolset in the first place?

@jasonmalinowski I was told the team had issues with the 7.0.10x SDK and had to reference Microsoft.Net.Compilers.Toolset to work around those. @geeknoid / @tekian can provide more information on that.
The issue manifested itself when I tried building against .NET 8.

[jaredpar]

The Microsoft.Net.Compilers.Toolset package is not officially supported for 3rd party consumption for this reason. It is a NuPkg that is designed to meet the infra requirements of the .NET team. It's also a tool for the Roslyn team to ship hot patches to customers, debug issues, etc ...

The documentation for the package is very explicit about this

This package is primarily intended as a method for rapidly shipping hotfixes to customers. Using it as a long term solution for providing newer compilers on older MSBuild installations is explicitly not supported. That can and will break on a regular basis.

[jasonmalinowski]

Any idea why you have that reference to Microsoft.Net.Compilers.Toolset in the first place?

@jasonmalinowski I was told the team had issues with the 7.0.10x SDK and had to reference Microsoft.Net.Compilers.Toolset to work around those. @geeknoid / @tekian can provide more information on that. The issue manifested itself when I tried building against .NET 8.

Yeah, this is something we probably need to do a better job then: if we're suggesting this package be installed for some specific case, we need to clearly communicate when we think that reference can be removed. Otherwise you're running a workaround that will indeed only explode later, as @jaredpar warns. Not your fault, just a lesson for us.

[RussKie]

@jaredpar I kind of feel we're talking about different issues here. I'm not arguing that this package has to work long term. The issue is that there is no mechanism to know that a) this package is installed and b) it has to be removed. E.g., if one engineer installed a package to resolve an issue, another engineer may not know that, then upon the SDK update everything breaks. Even if there's some kind of comment next to the package reference import, how would the second engineer know what to look for given the current error message?

[jaredpar]

That is true for any package though. This package is explicitly not supported because we understand this can be the case and cause confusion over the long term in builds. We've gone as far as we can think of to make it clear this isn't supported without making it physically hard to install.

[PlastImpact]

I fixed the exact same issue by replacing the oldest dotnet Microsoft.NET.Sdk.Razor.SourceGenerators.dll file with the latest. In my case this was updating the dotnet 7 file with the dotnet 8 file so that they matched. Put simply, copy paste the Microsoft.NET.Sdk.Razor.SourceGenerators.dl file from the newest dotnet "source-generators" folder to the other versions of dotnet within the same folder name. Hope this makes sense.

[nagilson]

I hit this trying to build an older branch of the .NET SDK because the global.json from arcade was pinning to an older assembly version. Anyone else who hits this with a dev sdk should try to update their eng folder to match main if using a newer preview SDK.

[EdLichtman]

A little late to the party

--

For me, it was a matter of "Am I using MsBuild or DotNet sdk"?

The issue is a lot more visible when viewing your code in Rider...

As you can see here, there is the dotnet version, and the msbuild version of "ms build". The MsBuild version comes installed with Visual Studio and can't be modified as easily without upgrading your Visual Studio.

So in my problem, I had a .sln file with both .net core and .net framework csprojs. I could not build using dotnet because the .net framework didn't restore packages properly. And I couldn't build using MsBuild because I have analyzers using 4.7,0.0, but the MsBuild version of the analyzer was 4.5.0.0 as you can confirm in this picture:

So if you hit a rock like I did for... far too long, try seeing if your Visual Studio is up-to-date. I can now build both using the msbuild.exe.