Stylecopanalyzers: [Question] Is it possible to setup StyleCop analyzers from .editorconfig file?

[xaviersolau]

Hello,
Is it possible to setup StyleCop analyzers with a .editorconfig file? Replacing the stylecop.json file?
Or is there any tool to have the same rules configured the same way in both files?
Regards

[sharwell]

It is not currently possible to use .editorconfig instead of stylecop.json. It would make sense to add this support as an option.

[SeidChr]

You can configure enabling or disabling of rules and the severity of StyleCop analyzer warnings in the editor config. At least this works well in visual studio.

[JadaVonRuth]

If so, how exactly? I tried last month adding eg. StyleCop.SA1508.severity = information and it did not worked. Its not clear under which name rules are accessible, plus other rules names are always in lower case with underscores.

https://github.com/RehanSaeed/EditorConfig/blob/master/.editorconfig - in this example there is few rules mentioned and it works with installed nuget of stylecop but for other I havent found any determinable naming convention between stated rule names in config file and source code here.

[leoniDEV]

@JadaVonRuth You only need to click on the light bulb and in Configure or Suppress Issues option then you can select Configure SAxxx severity, but you need VS 16.4 preview 1 or, if you have at least VS 16.4 preview 2, you can also right click on the warning/error in the Error List, and choose set severity from the context menu.

If you have an .editorconfig file the rule will be added to the existing one, if there is no .editorconfig a new one will be created next to the .sln file.

The naming convention is valid for every analyzers and is pretty
easy: dotnet_diagnostic.<RULE_CODE>.severity the RULE_CODE depends by analyzers and is the code that you can see in the Error List (for StyleCopAnalyzer is in the form of "_SAxxx_"), anyway it is better to add the rules using the light bulb or from the Error List instead of manually edit the .editorconfig because this way you have also a useful comment which describe the rule.

The rules in the file you linked are the rules built into Visual Studio and you need to go in Option -> Text Editor -> C# -> Code Style, from here you can export the configurations that you sets in General, Formatting and Naming by clicking Generate .editorconfig file from settings

[JadaVonRuth]

@leoniDEV I thought dotnet_diagnostic.RULE_CODE.severity works only with built in analyzers, so i did not even try and after all it works for any analyzer, Perfect!. Thanks very much for clarifying that! I wrote some analyzers of my own, wanted to combine them with stylecop and I could not work out how to configure them in editorconfig since using assembly name was not working and official microsoft did not stated that anywhere when describing how to write analyzers. The rest I am familiar with.

[mikernet]

I can take this one ✋ I'll see what I can whip up later this weekend 🙂

[sharwell]

@mikernet Thanks, let me know if you have any questions about the new APIs for this (AnalyzerOptions.AnalyzerConfigOptionsProvider). The test library supports adding .editorconfig content to a test via SolutionTransforms. Here is an example from a different analyzer:

https://github.com/dotnet/roslyn/blob/99a216ad1e9e493d6f01a5496631eed5833d3bef/src/CodeStyle/CSharp/Tests/FormattingAnalyzerTests.cs#L269-L281

[mikernet]

I'm starting to familiarize myself with the code and formulating an approach but I have a couple of questions:

1. As far as I can tell, StyleCopAnalyzers is currently oblivious to .editorconfig - is that right? As in, Roslyn handles managing rule severities configured in .editorconfig, not StyleCopAnalyzers directly.

2. What should the precedent between .editorconfig and stylecop.json settings be if the same setting is defined in both files? Does it need to be based on where in the directory hierarchy they appear or can we just decide that one overrides the other? It doesn't look like we will be able to (easily) selectively choose the rules based on where in the hierarchy a particular rule appears since AnalyzerConfigOptions flattens everything. If one has precedent then stylecop.json winning makes more sense to me since it is project specific.

3. The current "manual" JSON wiring approach for the settings might make it rather cumbersome and fragile to add a second "manual" .editorconfig wiring on top that. My initial thought is that it may be better to switch to an object structure with attribute annotated properties that can be auto-mapped to both JSON and .editorconfig values, but alternative suggestions are welcome.

[sharwell]

What should the precedent between .editorconfig and stylecop.json settings be if the same setting is defined in both files?

I'm not sure it matters since having the options in both places will not be a common scenario. If one option performs better than the other, we should use that. Otherwise, we'll pick one for convenience and document it.

[manfred-brands]

@mikernet Did you have any luck trying this?

@sharwell At the moment we need to have the options in two places, the entries in .editorconfig are used by VS and the entry in stylecop.json for stylecop and they can be contradicting or have different defaults if not listed. This is the case for those settings that have entries defined in either file: indent_style vs useTabs and csharp_using_directive_placement vs usingDirectivesPlacement, etc.

@mavasani are there plans to make the code from Analyzer.Utilities.Options from the roslyn analyzers available to 3rd party analyzers like StyleCop and NUnitAnalyzers? including the aggregation of file added to 3.3. It would remove duplication in EditorConfigParser and the caching of results and allow all analyzers to use the .editorconfig for their configuration.

[mikernet]

@manfred-brands Been trying to get input from @sharwell as to what an acceptable approach would be for this but it hasn't gone anywhere 🤷‍♂️ It's going to be a good chunk of work so I'm not going to rewrite the entire option system without some kind of nod of approval indicating the PR will be accepted given the approach.