Emit a warning when insufficient compiler version is used with the SDK

[tarekgh]

Is your feature request related to a problem? Please describe.

Recently we were debugging a failing issue which a scenario using Microsoft extensions logging source generator which requires C# compiler 4.4. The user was using 2022 VS v17.3.6 which using C# compiler 4.3.0-3.22470.13 (80a8ce8d). The source generation in the project will fail to work and will end up with a compiler error like: C:\scratch\webApp\Program.cs(35,32): error CS8795: Partial method 'Log.Hello(ILogger, string)' must have an implementation part because it has accessibility modifiers. [C:\scratch\webApp\webApp.csproj] which gives a hint there is a source generation problem but not clear what exactly the problem is especially compiling the same project on another machine happens to use compiler version 4.4 make it succeed.

Note, the project we were debugging was disabling the warning CS9057 which was hiding more information about the failure. Had they not disabled this warning they would have seen numerous warnings:

  CSC : warning CS9057: The analyzer assembly 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\7.0.2\analyzers\dotnet\cs\Microsoft.Interop.JavaScript.JSImportGenerator.dll' references version '4.4.0.0' of the compiler, which is newer than the currently running version '4.3.0.0'. 
  CSC : warning CS9057: The analyzer assembly 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\7.0.2\analyzers\dotnet\cs\Microsoft.Interop.LibraryImportGenerator.dll' references version '4.4.0.0' of the compiler, which is newer than the currently running version '4.3.0.0'. 
  CSC : warning CS9057: The analyzer assembly 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\7.0.2\analyzers\dotnet\cs\System.Text.Json.SourceGeneration.dll' references version '4.4.0.0' of the compiler, which is newer than the currently running version '4.3.0.0'. 
  CSC : warning CS9057: The analyzer assembly 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\7.0.2\analyzers\dotnet\cs\System.Text.RegularExpressions.Generator.dll' references version '4.4.0.0' of the compiler, which is newer than the currently running version '4.3.0.0'. 
  CSC : warning CS9057: The analyzer assembly 'C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\7.0.2\analyzers\dotnet\cs\Microsoft.AspNetCore.App.Analyzers.dll' references version '4.4.0.0' of the compiler, which is newer than the currently running version '4.3.0.0'. 
  CSC : warning CS9057: The analyzer assembly 'C:\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\7.0.2\analyzers\dotnet\roslyn4.4\cs\Microsoft.Extensions.Logging.Generators.dll' references version '4.4.0.0' of the compiler, which is newer than the currently running version '4.3.0.0'. 

Describe the solution you'd like

When using SDK version (which allows source generation) with insufficient compiler version, should produce more logging to warn about the issue.

Additional context

This is easily can reproduce by creating a project and use the compiler version 4.3 and have some source generation code.

[tarekgh]

@ericstj feel free to add/edit the issue if I didn't capture anything.

[earloc]

Dunno if this is the right issue to piggy-back on. So kindly redirect me, if this is out of scope:

I have a similar situation in the code-generator I authored, where I´d love to update to the most recent package version of Microsoft.CodeAnalysis.CSharp, but this would break when codebases are built with f.e. a build-agent that only has .NET 6-Sdk (or older) installed (which is likely to hit many people).

This article here mostly describes the exact same situation I´m facing:
https://www.damirscorner.com/blog/posts/20221014-VersionsOfSourceGeneratorDependencies.html

I also tried to just bundle the used version of Microsoft.CodeAnalysis.CSharp with my analyzer (see this commit)
but this then may fail due to multiple assemblies loaded within the same app-domain, where types cannot be interchanged.

Unhandled Exception: System.InvalidCastException: 
[A]Microsoft.CodeAnalysis.CSharp.Syntax.CompilationUnitSyntax cannot be cast to 
[B]Microsoft.CodeAnalysis.CSharp.Syntax.CompilationUnitSyntax. 
Type A originates from 'Microsoft.CodeAnalysis.CSharp, Version=4.4.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\Roslyn\Microsoft.CodeAnalysis.CSharp.dll'. 
Type B originates from 'Microsoft.CodeAnalysis.CSharp, Version=4.4.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'LoadFrom' at location 'C:\Users\[USERNAME]\.nuget\packages\typealizr\0.8.3\analyzers\dotnet\cs\Microsoft.CodeAnalysis.CSharp.dll'.

To reproduce, just reference the (unlisted) version 0.8.3 of my TypealizR-package in a fresh console-project on a machine, where the installed sdk already utilize 'Microsoft.CodeAnalysis.CSharp, Version=4.4.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'

[KalleOlaviNiemitalo]

@earloc that might be more related to dotnet/roslyn-sdk#955 and #20355.

[earloc]

@KalleOlaviNiemitalo thx for the direction, but I don´t think that´s the correct issue. But thx for the effort!

For everyone else stumbling upon this: see dotnet/roslyn-sdk#1056

EDIT: gnahh, didn´t saw that second issue #20355 there. This looks like the right place. Thx again.

[baronfel]

@earloc Just following up - this seems like a problem with multitargeting an analyzer to support multiple Roslyn versions - does #20355 give you all the guidance you need to unblock?

[earloc]

@baronfel Yeah thx, I guess this issue contains the basics to enable my scenario. Just didn´t find any more documentation on how to actually achieve this. My experience with multi-targeting is a bit outdated... I once tackled with this just before (or around) .netstandard became a thing, back in the shared project-days.

I currently choose to just pin my dependency to remain supporting .net 6-sdk machines. Might revisit this, if users really have the need for even older sdk´s (or in the future, when the next LTS-release hits our machines later this year).

Luckily, my package doesn´t really do much with maybe latest fancy-pants features of the language, which might rise the need to actually support newer sdks. So that approach (pinning the dependency) is currently fine for me.

[rotanov]

I had similar case recently.

Wrote my first generator. The project using it worked all right on Windows, but crashed on Mac.
The crash was related to absence of generated code. In my case code generated by source generator is only accessed via reflection. So I read up the build log and found

CSC : warning CS9057: The analyzer assembly ... references version '4.7.0.0' of the compiler, which is newer than the currently running version '4.6.0.0'.

It wasn't clear enough for me from the message, that it leads to source generator actually not being used, but since there were no other culprits I googled, downgraded the code analysis package to 4.6.0 and that's it.

The project consuming generator is net7.0-win/mac, and I had latest VS and .NET7 SDK installed on both Mac and Win. I didn't test the case with .NET SDK installed and VS uninstalled on Mac. In such case however having different Roslyn versions embedded in toolchains (between .NET7 SDK Mac vs Win) would seems strange.

1. I suggest making CS9057 an erorr by default instead of a warning. Are there any downsides to it?

   That may be problematic however if it's hard to tell if analyzer is source generator or not at the point warning is emitted.

   I believe there are other warning like that, e.g. when source generating analyzer crashes.

2. The message could be made more clear by clarifying that analyzer is not being run because of that. And by specifying "why" an analyzer is "references version '4.7.0.0' of the compiler".