Stylecopanalyzers: Possible to nest/inherit stylecop.json?

Created on 17 Feb 2016  路  10Comments  路  Source: DotNetAnalyzers/StyleCopAnalyzers

We currently have a single stylecop.json file which is then linked into a number of different Visual Studio projects.

We would like to update this file to include appropriate copyright header information. However, our work is spread out (and owned by) multiple clients, even though code is shared between them. This means the different VS projects would need different copyright headers, but we still want them to share the other stuff.

Ideally, we would like to have some sort of "base stylecop.json" that includes the common rules they all use. Then there would be a series of client-specific stylecop.json files which would (somehow) reference the base one for inclusion and then also define the client-specific copyright information. Each project would then utilize the appropriate client-specific file to get both the common rules and the correct copyright information.

Is there any way to accomplish something like this right now?

Thanks

enhancement question wontfix

Most helpful comment

Is there a specific issue in the rosyln repository that could be linked to from here?

All 10 comments

I don't this is currently possible. The analyzers do not access the file system directly, the stylecop.json file is handed to the analyzer by Visual Studio / MSBuild. Nesting / inheritance is not supported by Visual Studio / MSBuild afaik.

Having said that, it would be possible to extend StyleCop Analyzers to consider multiple settings files and merge their contents. This would need a clear naming convention that will imply the exact order in which these settings files are parsed (assuming that files that are parsed later will override earlier files).

In your situation this would mean that you a have stylecop.json file with the shared settings and (for example) a stylecop_client.json file that would contain the client specific settings. Both settings files should than be added to a project. @cabadam would such a solution be somethings that you could work with?

Yes, I was originally thinking just utilizing the stylecop.json. However, being able to include multiple files in a format like you described would work as well.

@cabadam @vweijsters You can store the stylecop.json file at the root (or anywhere) and add it as a link:
image

That way you can edit it once and have it update everywhere. Lastly, once you do this once; if you copy and paste the actual item in Solution Explorer from one project to another, it will copy and paste as a link.

@dmccaffery, I'm replying for @cabadam since he's out of the office the remainder of the week.

We already using this technique to share a single stylecop.json file across multiple projects. The issue is that we now want to include header specifications in this same shared file. The problem we are trying to address is that the header will vary across projects that otherwise have the same stylecop.json. We are trying to avoid having to redefine the same requirements for the different projects that only vary slightly.

@thenadz Ah. Makes sense. I didn't fully understand what you were trying to do; was just trying to offer an alternative solution in case you weren't aware. :)

Any project migrating from stylecop might have relied on this type of inheritance as it was previously supported with Settings.StyleCop. It might be good to note that it is not supported with analyzers in the stylecop.json documentation or known changes sections. Link

For classic StyleCop we provided a NuGet package with settings for our company (internally). This was realized by linking into the NuGet package folder.
To migrate to StyleCopAnalyzers we would like to have such setting inheritance, too.
I think, this should be possible also without naming convention, but explicit loading and merging files, specified in the root json file, isn't it?

@lukas-ais As analyzers are currently portable class libraries, it would be non-trivial (and in my opinion undesirable) to add code to access a local file system.

The proposed solution with multiple specified settings files that would be merged could easily work with a custom NuGet package that would install a company settings part that could be augmented with project specific settings.

This will end up superseded by the ongoing work in dotnet/roslyn to generalize .editorconfig for analyzer authors.

Is there a specific issue in the rosyln repository that could be linked to from here?

Was this page helpful?
0 / 5 - 0 ratings