How to handle supported version of Roslyn, Visual Studio, and the .NET SDK

[jmarolf]

If the user sets <EnforceCodeStyleInBuild>true</EnforceCodeStyleInBuild> then they will load in the Roslyn code style assemblies.

The CodeStyle layer references the latest version of the roslyn compiler. This has worked great for now. .NET SDK 5.0.300 is only compatible with Visual Studio 16.11 so the compiler versions match in both the SDK and Visual Studio.

The question is: what should happen if the user installs a newer SDK and uses them with an older Visual Studio. Today if the user installs a .NET 6 preview SDK that will contain the 4.0 compiler, but no versions of Visual Studio exist that ship with that compiler today.

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

[jmarolf]

Options

1. The compiler adopts MSBuild loading behavior. Meaning that if an Analyzer targets a higher version (like say 5.0) but does not actually use any APIs from that version then it can be loaded and uses on older versions (such as 4.0). You only get loading errors when the analyzer uses an API that does not exist in the compiler that it is running under. This would still cause loading errors but cases that we see today for Code Style analyzers in the SDK are mostly caused by a version mis-match not actual missing apis.
2. Allow analyzers to multi-target different versions of the roslyn API so the compiler can fall back to a compatible version. This would add complexity on our end to the roslyn build but is otherwise an ideal solution from the custom side.
3. Have a policy that analyzers in pre-release SDKs will only work in the latest preview of visual studio and any other combination is unsupported

Proposal

I propose we work with the compiler team on option number 1.

[vatsalyaagrawal]

Design meeting conclusion: We should provide more meaningful errors to cusotmers when such a scenario occurs.

[Youssef1313]

@jmarolf Is this considered fixed with dotnet/roslyn#61261 ?