Require analyzers to target netstandard1.x or netstandard2.0

[tmat]

This requirement is needed for moving analysis to OOP.

Report a load error when an analyzer does not target netstandard2.0. We could start by reporting a warning and flip it to error later.

We currently support analyzers to be loaded from a VSIX package. This means the analyzer assembly can actually call VS APIs. For example, analyzer authors might have options UI for their analyzer. We need a migration path for these kind of analyzers. E.g. for the options UI, the recommendation would be to persist the options in .editorconfig file that the analyzer then reads.

We need to document this requirement and recommendations how to migrate existing analyzers that do not target netstandard2.0.

[tmat]

@jinujoseph @kendrahavens @mikadumont @mavasani

[jmarolf]

@tmat can you file an issue on the roslyn-sdk so I can remember to update all the templates to do this.

[sharwell]

@tmat netstandard1.x will also need to be supported

This requirement is needed for moving analysis to OOP.

Eventually it would be a requirement, but today our OOP runs with .NET Framework right? After the transition, netcoreappx.y (for some x.y) would be supported in addition to netstandard2.0.

This means the analyzer assembly can actually call VS APIs.

This was never officially supported, and even today would break for both FSA and Fix All scenarios. I don't believe a migration path is necessary.

[tmat]

netstandard1.x will also need to be supported

How can netstandard1.x be supported when the analyzer assembly needs to reference
Microsoft.CodeAnalysis.dll, which targets netstandard2.0?

Eventually it would be a requirement, but today our OOP runs with .NET Framework right? After the transition, netcoreappx.y (for some x.y) would be supported in addition to netstandard2.0.

Correct. Once we're in OOP and on Core we can also support netcoreappx.y.

This was never officially supported, and even today would break for both FSA and Fix All scenarios. I don't believe a migration path is necessary.

@mavasani Is telling me he saw analyzers doing this. So maybe they are broken already.

[sharwell]

How can netstandard1.x be supported when the analyzer assembly needs to reference Microsoft.CodeAnalysis.dll, which targets netstandard2.0?

The analyzers can compile against the public API of an older build of Microsoft.CodeAnalysis. Even the latest 2.9.x releases of dotnet/roslyn-analyzers do this.

Is telling me he saw analyzers doing this. So maybe they are broken already.

Some analyzers do, and they are broken in some scenarios already. The supported replacement is using the light bulb extensibility APIs directly.

[tmat]

The analyzers can compile against the public API of an older build of Microsoft.CodeAnalysis. Even the latest 2.9.x releases of dotnet/roslyn-analyzers do this.

I see. Makes sense.