Migrate to StyleCop Source Code Analyzer

[dotnetjunkie]

The Simple Injector code base is currently verified using the deprecated StyleCop VS extension. This extension hasn't been maintained for several years and shows parsing errors on lines that use newer (> 6.0) C# features.

Instead, the code base can make use of the new Source Code Analyzer for StyleCop. This has the following advantages:

• It actually works. No more parsing errors.
• The analyzer is actively maintained.
• No extension needs to be installed. Works automatically for every developer working on the code base.
• The analyzer runs on every build. Impossible to forget.

The repository currently makes use of Settings.StyleCop (XML) files that configure which rules should be applied. The new Analyzer, however, doesn't read those XML files any longer and the used settings have to be migrated to rule set files, the new stylecop.json format, and sometimes .editorconfig.

Unfortunately, migrating from Settings.StyleCop to stylecop.json can be quite time intensive. I haven't found clear documentation on how to convert the old XML to the new JSON and which settings to place where exactly. Should we start off with a rule set and configure exceptions? Or should we skip the rule set entirely and use stylecop.json with a little bit of .editorconfig, or should we use .editorconfig, with a little bit of stylecop.json?

[leoniDEV]

If I can make a suggestion (even if I'm not contributor to this project, but I'm a really satisfied user, I also bought your awesome book about dependency injection) is to use .editorconfig file only (or at least migrate slowly from ruleset to .editorconfig, if you need to support VS versions older than 16.3), mostly for two reason:

1. It is the intended, official and supported way to configure analyzers;
2. the integration with Visual Studio enable you to configure severity from lightbulb or from error list;
   Using the lightbulb/error list to configure severity is pretty straightforward, also edit the .editorconfig file by hand is pretty easy, given that the convention for the rules is really simple and predicteble.

I migrated all my analyzer configs to .editorconfig mostly through the lightbulb/error list, and some times also adding the rules by hand editing the file directly, using the Visual Studio UI also add a useful comment that describe the rules.

Anyway my experience about migrating ruleset to .editorconfig is based solely on my projects which are small and relativly simple so I don't know if this workflow fits also for a project like this.

Finally I also discovered this issue but I don't know how and if it works, I never used.

[dotnetjunkie]

Hi @leoniDEV, thank you for your valuable feedback and useful links. .editorconfig seems clearly the way to go.