These are chat archives for DotNetAnalyzers/StyleCopAnalyzers

2nd
Nov 2016
Jeroen Vannevel
@Vannevelj
Nov 02 2016 12:45
I cloned the project so I can disable/enable rules and export it as our own internal stylecop. That way we can just reference a single nuget without project-specific rulesettings
How would you suggest I do the actual enabling/disabling?
Sam Harwell
@sharwell
Nov 02 2016 14:36
@Vannevelj I would suggest using a rule set file.
I know it sounds like a good idea to hard code them, but really it's just asking for a maintenance headache.
Jeroen Vannevel
@Vannevelj
Nov 02 2016 15:58
you mean a ruleset file in every project?
the idea behind cloning StyleCopAnalyzers is so that every project just has to add a reference to it and they're all set
Sam Harwell
@sharwell
Nov 02 2016 16:00
You can use the same ruleset file in multiple projects
You could even put it in a NuGet package and install that package
Jeroen Vannevel
@Vannevelj
Nov 02 2016 17:38
That will still require you to modify every project to point to the ruleset file though, right?
Sam Harwell
@sharwell
Nov 02 2016 17:50
You could use a .props file inside the nuget package to inject the file into the build of any project that references it
There are two items in code that are likely of interest to you:
  1. The default severity, which is Warning for all of our analyzers but can be changed: https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/master/StyleCop.Analyzers/StyleCop.Analyzers/DocumentationRules/SA1605PartialElementDocumentationMustHaveSummary.cs#L84
  2. The constant AnalyzerConstants.EnabledByDefault. You could change individual cases where that is used to instead be AnalyzerConstants.DisabledByDefault, with the obvious expected result on the final library.
Johan Larsson
@JohanLarsson
Nov 02 2016 18:47
would be nice if rulesets worked like stylecop.settings
sln > proj