Roslyn-analyzers: Roslyn Analyzers vs EditorConfig

[MisinformedDNA]

Roslyn analyzers and .editorconfig can do some of the same things. For instance, now we can define capitalization rules within .editorconfig or use the StyleCopAnalyzers.

When Rolsyn analyzers came out, I thought this would be the standard way of doing things, but there seems to be a shift to .editorconfig. Even you guys use it! I can see some use for editorconfig for non-dotnet, non-csharp settings, but I don't understand why we need two different ways of accomplishing the same things... and why you all aren't eating your own dogfood?

[mavasani]

@MisinformedDNA I am wondering if you meant "Ruleset" and not "Roslyn analyzers" here. Analyzers are compiler extensions that do analysis and report diagnostics. "Ruleset" and ".editorconfig" files are themselves not doing any analysis, but are just configuration files that determine/configure behavior of installed analyzers. Rulesets are the legacy file format used for analysis configuration, and we are slowly moving towards replacing them with .editorconfig based configuration.

[MisinformedDNA]

Oh, OK. So editorconfig actually uses the analyzers, that's good. So right now, the editorconfig is actually using built-in analyzers? Is that built into VS or Roslyn?

Is there information on third-party Roslyn analyzers integrating with editorconfig?

[mavasani]

Rule configuration and analyzers are completely separate things that work fine with each other. We are currently working on adding .editorconfig support to the C#/VB compilers, so that .editorconfig can be used for configuring any third party analyzer for CI + IDE, not just the VS-built in analyzers in IDE. At the same time, we are working on NuGetizing the VS-built in analyzers so they work on CI. Once all of this is done, there will be a consistent story:

1. Both VS-in built analyzers and third party analyzers (StyleCop analyzers, Roslyn based FxCop analyzers, etc.) can be configured with .editorconfig or ruleset files, with .editorconfig being the preferred modern way and ruleset files being legacy configuration.
2. All these analyzers have NuGet packages that can be installed to projects and then run in CI builds and break build + will also run in the IDE. They will respect rule configuration from both .editorconfig and ruleset.

I hope this clarifies things.

[gewarren]

We have a docs FAQ page available now.

[sunefred]

At the same time, we are working on NuGetizing the VS-built in analyzers so they work on CI. Once all of this is done, there will be a consistent story:

This is awesome news. If I understand you correctly the built in VS-analyzer, incuding all its language specific style rules, is going to be moved to a NuGet? Is this effort aligned with FxCop or a separate project?

[mavasani]

Yes that is correct. This is a separate project driven by @sharwell. Note that there is already a preliminary code style package with just the formatting analyzer on myget. He can provide you more details if required.

[Wraiyth]

@mavasani I've been looking around for the formatting analyzer on MyGet, any direction for that one? I'm interested in being able to make some custom formatting rules which can be driven by a .editorconfig file and apply as you type.

[mavasani]

I've been looking around for the formatting analyzer on MyGet, any direction for that one? I'm interested in being able to make some custom formatting rules which can be driven by a .editorconfig file and apply as you type.

Tagging @sharwell @JoeRobich for questions on dotnet format and the formatting analyzer.

[ElteHupkes]

For others ending up here through some Google search, this package contains the formatting analyzer following .editorconfig:

https://dotnet.myget.org/feed/roslyn/package/nuget/Microsoft.CodeAnalysis.CSharp.CodeStyle

So that basically covers the second convention category. I'm curious though if there are any (preliminary) packages doing the same for the other categories? It's super practical getting build errors / warnings for formatting mistakes, it would be even better to have it for naming errors :).