Stylecopanalyzers: Solution wide stylecop.json file

[huserben]

Is it possible to have only one stylecop.json file which is valid for all projects within the solution? I think in legacy StyleCop it checked the parent folders for the settings file and took this one if it was found. Something similar would be nice, otherwise the file has to be copied to each and every project and it has to be made sure that for new projects this is done as well.

[sharwell]

We currently implemented such a solution for this project using linked files (commit 59ec26047feb55c040cd021a2e75b4cb09630066). You'll need to add the same stylecop.json file to each of your projects as a linked file, but then it will work.

[huserben]

Ok, is it likely that it will stay this way or is it planned to somewhen have the same behavior as legacy StyleCop had?

[sharwell]

This (simpler ability to configure analyzers) is something the Roslyn team is discussing as a new feature which would benefit many analyzer developers. Right now the process is manual but I hope to have more information in the "reasonably near" future. :smile:

[huserben]

Ok thank you, then I guess we will go with the "linked file" approach until there are further news ;-)

[xperiandri]

Any progress?

[sharwell]

@xperiandri You can follow dotnet/roslyn#7071 for updates on this.

[d1mnewz]

Also experiencing the same issue, that solution-wide stylecop would be really very useful for big solutions with big teams.
The linked file approach feels more like workaround or a trick.

[xperiandri]

@d1mnewz, looks like it is deprecated in favor of .editorconfig which is supported in VS2017

[sharwell]

@xperiandri Currently .editorconfig is only supported for some of the built in analyzers that ship with Visual Studio 2017 (the ones that have diagnostic IDs IDExxxx). We're working to expand .editorconfig to everyone, and which point it will become the recommended approach for analyzers that require configurability.

[TheXenocide]

So it sounds like stylecop.json honored linked files which made it possible to share configuration, but it looks like .editorconfig does not honor linked files (at least from my experiments in VS 2019 16.4.0 Preview). I have asked the following question on StackOverflow regarding how we might be able to best share configuration across many projects/solutions/repositories without guarantees of a common directory hierarchy, but as this conversation seems related I thought I'd also ask here. Ideally this would allow us to specify this configuration via a NuGet package that every project in our organization already references for Code Analysis configuration. Any insight would be helpful.

[sharwell]

@TheXenocide .editorconfig is by definition directory-based. There are no current plans to deviate from that requirement of its specification.

[TheXenocide]

Directory.Build.props is directory based as well, but it's certainly helpful to be able to include a props file explicitly too; surely people have to be considerate of how they organize these when order matters, but the presence of one does not ignore the usefulness of another. I understand this isn't the same thing and I understand that there's a certain amount of expectation defined by the standard that is agnostic from visual studio, but I'm not so much asking to change anything about the directory-oriented inheritance hierarchy and I'm sure there are plenty of other valuable improvements to focus on. My first hope was that the editor would honor linked files (which have explicit directory locations and function just like a file actually existing at that location for the purpose of literally every single other tool I know of in the editor). It appears this feature worked in previous incarnations of coding standards and has been lost in migrating to .editorconfig.

We're discussing other options, but it's really very unfortunate that there's no way for a team to share a single version of .editorconfig across many repositories without just copy/pasting one to the root of the C drive (or some glorified/maintenance-multiplied version of that). Package Management solves exactly this problem for so many other similar problems (code analysis configuration and tooling, linters, aspect tooling/configuration), this is literally the only coding standard configuration we're not able to control from a package at the moment. For the teams that are currently sharing a single .editorconfig across multiple repositories guaranteeing this is a point of a lot of additional maintenance and scripting where it could otherwise be quite simple. Admittedly the file itself is less likely to change than most, but changing it is still quite a tax when the same settings either need to be replicated everywhere or a script that only has any work to do once a year is running on every build or every time we get latest from source.

All that said, I also see that this is an older conversation on the subject and I was mostly hoping to find a solution to a problem we have struggled with multiple times and have yet to find an ideal simple solution. If none exists then none exists. If there's no intention to support any other method of sharing this configuration then no solution will exist (at least for the foreseeable future). That answers enough of my questions for now so I can at least stop searching. Thanks kindly for the help.

[Jothay]

@sharwell I've seen .editorconfig mentioned as becoming the common source for analyzer devs to write points to, at least as var back as 2017. Did .editorconfig ever actually replace stylecop.json? If so, where is the documentation that points to how to configure it appropriately? The Documentation folder here still only refers to stylecop.json

[sharwell]

@Jothay Eventually https://github.com/DotNetAnalyzers/StyleCopAnalyzers/pull/3285 should allow .editorconfig to replace stylecop.json.