How do i disable StyleCop for a project or whole solution?

[Robban1980]

I'm having the issue of not being able to disable stylecop for individual projects or a whole solution. Only help online i can find is for previous non versions of StyleCop. Anyone have any tips on how to do it?

[sharwell]

It sounds like you are using what we refer to as StyleCop Classic - the original StyleCop before it was rewritten for the new C# compiler. If that is the case, you'd have to check with the original project (I'm not sure if/where it's still around).

If you are using StyleCop Analyzers, then it's only applied to projects that have the StyleCop.Analyzers NuGet package installed. Uninstalling the package from a project will disable the analysis for that project.

[Robban1980]

Thanks for the reply @sharwell, i'm using StyleCop Analyzers. Was hoping it would be possible to disable during builds with a flag. It has a bit too much impact on Debug build time, unless one has a powerful CPU.

[sharwell]

@Robban1980 Perhaps you are interested in #1711?

[Mattacks]

@sharwell "Uninstalling the package from a project will disable the analysis for that project"
Not for us it doesn't. We have a small Core solution, and want checking only on some. Only those have the package installed. Yet checking is being carried out on all the projects.

I would say there is a bug here.
Maybe it is because these project reference projects with analysis on?

[aboo]

@Mattacks and @sharwell we are experiencing the same issue.

In our situation, We have a .Net Core project in VS2017 which has StyleCop.Analyzers package installed. Then we have a second .Net Core xUnit project where we don't want that being StyleCopped. However since we have to reference the first project apparently the Analyzer will get enabled as soon as you reference a project which has the Analyzer package installed.

Is there any workaround?

[bjornhellander]

@Mattacks and @aboo, make sure to report this to the Roslyn team (https://github.com/dotnet/roslyn) if it hasn't already been done. Individual rules are supposed to be activated depending on if the analyzer is referenced in a project and if the rule is configured to be run according to the ruleset file, so if for example StyleCop Analyzers are getting executed on a project it's not configured for then that indicates a problem somewhere else, probably in Roslyn itself.

As a workaround, you could try configuring a different ruleset file for the test project with all rules turned off. See if that works.

Otherwise, you could try to suppress all StyleCop warnings in that Project (Project properties -> Build -> Suppress warnings). No fun, but it might be ok as a work-around.

Other than that, I can't think of anything to get rid of them completely.

What I think you really should do, is to actually have StyleCop referenced in the test project as well, but possibly disable some rules that you think is unnecessary by using another ruleset file for that project. Most of our rules are equally applicable to test code... But that's only a suggestion :-)

[aboo]

Thanks @bjornhellander. We've already done the workaround of having another ruleset for the test projects.

I will follow this up with Roslyn team.

[ryantrem]

@aboo - any update on this? I looked at Roslyn issues but didn't see any mention of this issue. Did you log an issue there?

[aboo]

@ryantrem Nah I was too lazy to file an issue :) We've decided to use different rule-set for our test projects. The reason is that we realized that we need some of the rules but not all of them.

[powellcj12]

I was running into this as well and finally managed to figure out how to exclude StyleCop.Analyzers where I needed to. Similar to @aboo I have an xunit project (which I don't want analyzed) that references/consumes my class library (which I do want analyzed). I'm using .NET Core on Mac and just had to make sure that when including the package in my class library, I explicitly set the PrivateAssets attribute to All and then any projects consuming my lib weren't being analyzed:

<PackageReference Include="StyleCop.Analyzers" Version="1.0.1" PrivateAssets="All" />

What I found strange was that according to the Microsoft docs, analyzers should already be part of the default PrivateAssets. If I specified just analyzers explicitly in the PrivateAssets attribute, it would still not work as expected.

I'm a little new to NuGet, Roslyn, etc. but based on the documentation I wouldn't have expected this to be necessary. Could it be that Roslyn doesn't consider StyleCop.Analyzers as an "analyzer"? I'm happy to file something at Roslyn to get this straightened out because it did cause me quite a few headaches...

[ryantrem]

I ended up not logging an issue with Roslyn because I was not able to repro this after updating to Visual Studio 2017, so I assumed it had been fixed. @powellcj12 which version of VS are you using? I thought was a NuGetv 4 feature and that NuGet v4 was only included in VS2017, but I could be wrong...

[powellcj12]

@ryantrem I'm on a Mac just using the dotnet CLI (v1.0.1) which claims to be using v4.0.0.0 of NuGet CLI:

$ dotnet --version
1.0.1
$ dotnet nuget --version
NuGet Command Line
4.0.0.0

But I think that's just the version of the CLI tools, not the library/binaries themselves. Based on this article, it seems like MSBuild is now really the thing responsible for restoring packages.

$ dotnet msbuild /ver
Microsoft (R) Build Engine version 15.1.548.43366
Copyright (C) Microsoft Corporation. All rights reserved.

This all just came with the .NET Core 1.1 SDK that I installed, which I believe is also what's included in VS2017.

[CreepyGnome]

If I am understanding correctly I see some issues by StyleCop.Analyzers being a PackageReference in a CSProj file.

1. If you publish a NuGet package that depends on StyleCop.Analyzers you are no making everyone who wants to use your NuGet package also take this dependency
2. If you take a dependency on a NuGet package that also has a dependency StyleCop will run on my project as well, when I may not want

From what I have read and seen it seems like making this a NuGet package doesn't make sense.

Feels like an open source project that releases their API's via NuGet and uses StyleCop.Analyzers will make the API dependencies to heavy and most likely cause the project to not be taken up as quickly or at all.

It seems like either PrivateAssets set to All shouldn't be required, or should be set automatically. Plus it seems like PrivateAssets set to All can be defeated as reported in this Issue: dotnet/sdk#1808

Is there something missing? Is there no way for a NuGet package when referenced to ensure it is always set to be Private for its direct consumer?

Therefore my big question is HOW can I use the new StyleCop Analyzers without making it a dependency on my projects?

Or is the only way to use the NuGet package and then manually have to change a setting on its PackageReference on CSProj file?

Since DotNet SDK Issue 1808 is still open is this an issue that could cause issues for consumers of NuGet packages that use StyleCopy.Analyzers even when they set SyleCop to be private?

[sharwell]

@CreepyGnome

If you publish a NuGet package that depends on StyleCop.Analyzers you are no making everyone who wants to use your NuGet package also take this dependency

This will only happen if the package was created with this dependency. The PrivateAssets="all" attribute on the package reference will suppress this dependency when the NuGet package is created.

If you take a dependency on a NuGet package that also has a dependency StyleCop will run on my project as well, when I may not want

This should only happen in cases where it's desired, e.g. a NuGet package whose purpose is to install and configure StyleCop Analyzers for a specific team/company. If you are seeing this as a transitive dependency of an unrelated library, it means the library was incorrectly authored (the PrivateAssets="all" was omitted).

Plus it seems like PrivateAssets set to All can be defeated as reported in this Issue: dotnet/sdk#1808

I believe this applies only to assembly references, and not to analyzers.

Is there something missing? Is there no way for a NuGet package when referenced to ensure it is always set to be Private for its direct consumer?

We've taken measures to the extent we know how. If you find a better way to do this please let us know.

StyleCopAnalyzers/StyleCop.Analyzers/StyleCop.Analyzers.CodeFixes/StyleCop.Analyzers.nuspec

Line 16 in 1c3c14d

<developmentDependency>true</developmentDependency>

Beyond this, our "hands are tied" so to speak by the implementation of NuGet itself.

[CreepyGnome]

@sharwell

Looks like there is an open issue being worked on to allow this.

NuGet/Home#4125

Looks like some very smart people want developmentDependency in the nuspec to trigger the setting of PrivateAssess to all when the package is added. Looks like they are trying to get this in... its a very long thread. However, when they implement this and release it your nuspec should be perfectly fine as is.

Thanks for the response.

[Denis535]

I have a similar problem.
I experimented with StyleCop but now I can't disable and remove analyzer.
I removed stylecop and analyzer lines from Directory.Build.props, packages.config, *.csproj, *.sln but I still seeing many warnings.
it only helped me to rename folder with solution. But if I rename back my folder then problem is back. What's goin on? Visual Studio can cache settings?

[Denis535]

I removed obj folders and it's helped me ))

[sdg002]

Thanks for all the information on this post. We ran into a similar problem . Adding PrivateAssets="all" to the CSPROJ of our custom package, after adding a reference to StyleCop solved the issue of unwanted propagation. We are on .NET Core 2.2 and Visual Studio .NET 2019

[twojnarowski]

Is there a way to disable the rules for a #region of code? Not the whole file, not one method, but a couple of methods combined in a #region?