Stylecopanalyzers: Implementing StyleCopAnalyzers in a existing solution?

[snowjim]

Hi,

We have a existing solution containing 50 projects, adding the StuleCopAnalyzers to just one of these projects genereates 145 000 warnings! It also drags down the build time alot. My first thought was to disable StryleCopAnalyzers per default and just show the intellisense but I can´t find a way to do this?

Our nightly builds(done on team server) do not accept build warnings at all so we want to :

• Make sure there is no build warnings when building at the team server
• Still be able to sett StyleCopAnalyzers warnings when needed
• Full intellisense help based rules.

How do I implmenet StyleCopAnalyzers the best way in a solution like this? Or is StyleCopAnalyzes not the right tool in this case?

[kseitz10]

I'm curious if there are any recommendations for this as well. I was searching for a way to turn off background code analysis because of performance issues -- especially with ReSharper running -- but did not find a way. We have hundreds of thousands of violations because we've neglected to run the old StyleCop extension consistently. I guess that's the price we pay...

My first thought was to disable StryleCopAnalyzers per default and just show the intellisense but I can´t find a way to do this?

The approach I've been using so far is to set most/all of the analyzer outputs to Info rather than Warning. The end result seems to be that the build process is faster because it doesn't contain so many warnings, but the user can still see the indicators within the VS editor when rules are violated. You can look at the _Error List_ window in VS to see violations in the files you've opened. Using the toggle for the _Messages_ severity allows you to show/hide these violations. If you don't want to hide messages from other sources, you can choose to filter the error list to _Build_ items instead of _Build + IntelliSense_ items.

You could also swap out the code analysis rulesets in different build configurations, e.g. debug could output rule violations as warnings whereas release (or whatever your build server uses) could disable the output.

[vweijsters]

Creating a custom rule set and setting everything to info is the only thing that I can think of as well.

And don't forget that you can use the code fixes to perform multiple fixes (on both project and solution level) in one go (link) . That may reduce the number of warnings significantly in a short time.

[sharwell]

Having helped several projects adopt StyleCop Analyzers, my recommendation at this point would be the following:

1. Understand that while we take great pride in a product that performs exceptionally well, our performance work focuses on cases where no warnings are reported, as this is the steady-state behavior for projects that use StyleCop Analyzers.
2. Start by disabling all of the rules except the ones that start with SA0.
3. (Optional) Run StyleCopTester on your solution to find all diagnostics currently reported. You will likely find many rules which do not report any diagnostics. You can enable these rules from the start without problems.
4. Enable the rules you want to enforce one at a time. When you enable a rule, fix all violations of the rule using the Fix All feature provided for the rule. Avoid making multiple large changes in the same commit, since it is much easier to review single-topic changes for correctness.

[arphox]

I have created a ruleset which contains all StyleCop rules explicitly set to None, so for existing solutions, this could be useful.
See it here.

_(Source of rule names: here, all included that start with SA or SX, except SA0002 which is incredibly useful to know about I think)_

[oniric85]

@sharwell is there a way to use StyleCop code fixers in JetBrains Rider too?

[sharwell]

@oniric85 I'm not familiar with that environment specifically. The code fixes are intended to work in any IDE that supports Roslyn's code fixes API.