msbuild: Version mismatch between Roslyn in MSBuild and CodeStyle analyzers in the SDK

Forgot to publish our meeting notes on how we’re going to move forward with this. In short:

1. Roslyn is going to produce a package containing the desktop compilers: Microsoft.Net.Compilers.Framework.
2. .NET SDK is going to support a new property inside of Directory.Build.props called <UseRoslynSdk>. When this is truthy and building from .NET Framework the desktop compilers will be installed and used vs. grabbing the compilers from the MSBuild install

This will fix the analyzer / generator inconsistency issues because it means the desktop compiler will match the expected API for analyzers and generators.

This broke DocFx too:

https://github.com/dotnet/docfx/issues/8097

the 7.0.3xx port was approved for release in July. There won’t be earlier ports as 7.0.2xx is out of support and the Roslyn side changes aren’t in 17.4 (7.0.1xx).

We changed to using BuildWithNetFrameworkHostedCompiler instead of UseRoslynSdk.

PR is here: https://github.com/dotnet/sdk/pull/29787

So yes! We now support that. I also have a PR out to backport it to 7.0.3xx; we’ll see if we need it in an earlier branch or not later.

The code style analyzers are version-locked to the version of Roslyn they are developed against. Other analyzers target earlier versions of Roslyn, but these cannot. The only available option is to downgrade global.json to an earlier SDK, or update Visual Studio to a newer release that matches the SDK.

The code style analyzers are frequently updated to use new syntax APIs as the compiler creates new features, and there is no straightforward way to lock the code style analyzer package to an earlier version of Roslyn that does not provide those APIs. We originally tried to avoid this, and it resulted in multiple prolonged cases where the code style analyzers in the SDK failed to recognize new language features with many user-visible bugs as a result.

I honestly think it’s a bad experience for our ecosystem and we need to move the analyzers from SDK into the MSBuild toolset next to the Roslyn compiler binaries.

It’s unfortunately not that easy. It requires a significant amount of reworking of the targets in addition to that.

I think even if it fixes just the CodeStyle analyzers, it will be a huge win

I agree it’s a win but it’s also work that doesn’t actually fix the problem. It’s a “fix Microsoft but leave the community behind” type of fix.

I think even if it fixes just the CodeStyle analyzers, it will be a huge win. In my view we need to decouple this from the general “fix all analyzers” problem as that seems much more monumental.

I just cloned a repo that targets 17.3 on a machine with 17.2 and getting these:

  CSC : error CS8032: An instance of analyzer Microsoft.CodeAnalysis.RemoveUnnecessaryNullableDirective.CSharpRe
       moveUnnecessaryNullableDirectiveDiagnosticAnalyzer cannot be created from C:\Program Files\dotnet\sdk\6.0.400\Sd
       ks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CSharp.CodeStyle.dll : Could not load file or assembly
       'Microsoft.CodeAnalysis, Version=4.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its depend
       encies. The system cannot find the file specified.

I honestly think it’s a bad experience for our ecosystem and we need to move the analyzers from SDK into the MSBuild toolset next to the Roslyn compiler binaries.