Roslyn: Exclude files or folder from running through the analyzers through a configuration file.

[mantzas]

Hi,

we have a lot of generated files that trigger warnings, errors when analyzers run them.
since the file name of the generated files do not follow the common naming conventions for generated code roslyn fires the analyzers away. As a result there are ten of thousands of warnings in the solution.
Could we get a exclude file from analyzing logic that:

• Exclude a file by adding it to a exclusion list
• Exclude a file by adding it to a exclusion list
• Annotate classes with a special Attribute that exclude the class
• exclude certain file name extensions ( like js files generated by typescript)
• Combination of the above like exclude all js files that live under the folder x including all sub folders

Most of the rules come straight from Resharper's exclusion file manager

Thanks

[lgolding]

See #5162. The author of that issue (@vbfox) has some feedback on the solutions proposed above.

[RazPopov]

This issue is really annoying, it prevents people from using these analyzers on WPF projects. I thought I'll add a vot to this and mention that it took me a while to get find this place, so please don't consider this something that nobody cares about. I can tell you that more than half of my team is bothered by this problem

[srivatsn]

We want to provide a way for analyzer authors to simply say don't report issues in generated code. The diagnostic engine will have a set of heuristics that define "generated code". However we need a configuration file that users could use to define generated code, like the rules mentioned in this issue. We'll use this issue to track the need for such a configuration file.

[codybaxter]

Why does this issue keep getting moved out. I am working on a team that has several .NET Projects where we use the new Analyzers. We had several rules turned on before transitioning to Roslyn and VS 2015 that can't be turned on now because of this. Having this fixed would be a big win for the new Analyzers. As this is preventing them from really being used to their full potential.

[jake-brandt]

Ignore my rambling; environment issue on my end (deleted original comments).

[brunocunhasilva]

As I mentioned on another post, this missing feature is a huge blocker for adoption on big projects with lots of legacy code/files.
https://github.com/DotNetAnalyzers/StyleCopAnalyzers/issues/726

We simply cannot afford to go fix or suppress tens of thousands of warnings...

[normanhh3]

This is currently an issue for me with an Orleans code-gen file whose name is "orleans.codegen.cs" that is being processed by the code analysis analyzers. @sergeybykov any thoughts or pointers on how you guys are using code analysis tools?

(Specifically one set of analyzers I am using are the new StyleCop analyzers.)

[sergeybykov]

@normanhh3 What version of Orleans are you using? In 1.4.0 we removed orleans.codegen.cs from being explicitly included in .csproj files.

[jdom]

@sergeybykov, the point is that even if we don't include the file in the csproj, it is still being analyzed from the obj folder and reporting errors (see https://github.com/dotnet/orleans/pull/2816 , which is a poor workaround).

I've been reading through the links here, and I spotted a regex here: https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/d10db47a8777dc882ef196d78692a1ece67bbb1d/StyleCop.Analyzers/StyleCop.Analyzers/GeneratedCodeAnalysisExtensions.cs#L113

Does it mean that if instead of calling our file assemblyname.codegen.cs we start calling it assemblyname.orleans.generated.cs then we would be excluded from the analyzers?

[normanhh3]

I guess my reason for posting here, is that it looked like there was a thought that a configuration might exist to control which items get analyzed.

@sergeybykov we are using version 1.3.0.0 right now so it sounds like a minimal workaround would be to move to 1.4.0.0?

[normanhh3]

This issue from the StyleCop analyzer project actually led me to investigate the Roslyn side of the issue.

[DuncanMillard]

Just another +1 for this issue. I generate c# using .tt files and I'm getting CS1591. Because I control the .tt files, I can add in the appropriate #pragma but I'd love the <autogenerated> tag that's already in there to be respected for the more general case.

[pavele]

Do you think that we can provide a fix that is implementation which respects <auto-generated /> correctly for the different languages. The format would be correct single line comment statement like these:
c#:

// <auto-generated />

vb:

' <auto-generated />

This is causing serious problems in plenty of places and it is blocking the adoption of the analyzers. StyleCop and EntityFramework are respecting this but it pops up constantly in different places and such simple project approach is probably the best option.

[harshil93]

Any update or workaround for this ? I want to exclude some of the files in my project for analysis on case by case basis

[normanhh3]

It looks like since this issue hasn't gotten assigned yet, it is going to languish here.

Anyone know who on the team to talk to so we can at least get this first stage triaged?

@sergeybykov maybe you have some leads here?

[sergeybykov]

I don't have any leads. Can semi-randomly tag @terrajobst.

[jmarolf]

@jinujoseph owns this area

[sucaritas]

Its been two years since this issue was opened, can we get an ETA on this?

[sharwell]

@sucaritas This was mostly fixed a long time ago. If you are still running into the problem, we'd need to see more specifics about the situation. The primary manner for exclusions already implemented is described in https://github.com/dotnet/roslyn/issues/3705#issuecomment-333144153.

[abogarsukov]

The <auto-generated/> tag is not enough. As Unity3d developer I have to deal with projects that contain lots of 3rd party source code (plugins). Inability to specify ignore folders for analyzers makes tools like stylecop unusable for such projects (can't really tag hundreds of 3rd party files as auto-generated).

[pavele]

Modifying the files is not a good approach in general and especially when you have plenty of files that are "externally" created.
I'd suggest to have a file with similar syntax to gitignore files. This I believe is universal and very flexible approach that will solve most of the problems if not all of them

[bussemac]

As an example, we enforce "Code must not contain trailing whitespace" (SA1028). A 3rd party nuget package installs a .cs file that contains trailing whitespace, and so every time we update the package, we have to manually edit the file, which means next time we go to update we have to confirm that we want to overwrite the file. Being able to simply exclude it (like from the .csproj) would be ideal.

[jake-brandt]

I think ideally we could implement something like an <analyzers-ignore /> block in .csproj files which supported globbing ("./obj/*/" for example). Something somewhat close to patterns in Git (.gitignore file) and Gulp (gulp.src())?

I may fork this, time permitting, and see what's in the way of getting such a feature in.

[tmat]

A couple of thoughts
1) Some analyzers must run on all files, no matter whether they are generated or not. For example, a security rule analyzer needs to flag issues in generated code as well.

2) Wouldn't .editorconfig file be a good place to specify what files to ignore? Security rules that shall apply to the entire project need to be specified in a ruleset file rather than in an .editorconfig file, since the project can link a file that is outside of the directory containing applicable .editorconfig file. So perhaps we could specify something like [obj/**/*.cs] suppress_analysis=true in .editorconfig file. This suppression would apply to all rules (and only to those rules) that can be specified in .editorconfig file. It would not apply to rules enabled in a ruleset file.

[bussemac]

I've got a lot of projects using rulesets ... I wouldn't want to have to convert all those over to editorconfig just to work around a poorly designed (but still useful) Nuget package. Maybe it's okay to just not let suppression work on security rules, but work fine on other rules defined in ruleset.

[tmat]

@bussemac Good point. Maybe we just need rule categorization. A rule can declare whether it is allowed to be suppressed or enabled in .editorconfig and/or a ruleset. Then suppress_analysis in .editorconfig would suppress all rules that are allowed to be suppressed in .editorconfig, but would not apply to rules that are ruleset-only.

[MisinformedDNA]

@jinujoseph Can we get an update on this?

[jinujoseph]

I hear the concern and this has been in our TODO list for a long time.
Marking this for design review, which will help us to cost + prioritize over other imp issues in plate.

[MisinformedDNA]

In the meantime, I added // <auto-generated>Blah blah blah</auto-generated> to the top of some of my *.cs files, but I'm still getting analyzer warnings. I thought this was supposed to work, no?

UPDATE: It is working... most of the time. I think I'm seeing a few issue types that are always reported even within generated code. I'll file a separate issue for that.

[rolandh]

Any updates on this? I have some massive static lists in a class that adds a solid 500ms to the analyser ever time I make any changes that reference that file. Slows everything down. I'd love to be able to tell roslyn to just go away completely and rely on resharper.

[MisinformedDNA]

@rolandh https://stackoverflow.com/a/36866362

[rolandh]

That doesn't do anything. Live analysis still runs constantly in the background. You can see it take 10 seconds to parse some files, even with a 12 core thread ripper and a raid 0 nvme pci ssd. I just want to disable it but it seems impossible to do.

[ssg]

We need a folder-based exclusion mechanism for EF migrations. EF team refuses to add "autogenerated" tag at the migration file headers because they say "those files are meant to be manually edited". It's impractical to add migration files one by one either as that complicates development process immensely.

I think a .styleignore like mechanism mentioned above by @pavele would be the most usable. It would support all the scenarios mentioned at the top comment, including folder based exclusions, and would involve minimal parsing overhead.

[sharwell]

@ssg The Code Cleanup feature we're working on is intended to address scenarios where files added to a project do not currently conform to the project style but need to. I would expect it to address the majority of limitations in the current EF migrations scenario.

[ssg]

@sharwell Thanks! As long as it doesn't require our developers to "remember" to run it after introducing a new migration, it's all great.

[pbaelen]

+1 for this one.
I have a bunch of non generated old files (in a StyleCoped project) that I don't want to care with their style.

[watsonsong]

Is there any way to support an exclude filter for analyzers?
I put some thirdparty c# code directly into my project and there code is not auto-generated. I just want to ignore analyze for them.

[kevingy]

@sucaritas This was mostly fixed a long time ago. If you are still running into the problem, we'd need to see more specifics about the situation. The primary manner for exclusions already implemented is described in #3705 (comment).

@sharwell The method in the comment you reference doesn't work. I added a reference to a service reference to my .NET Core 2.2 class library. Visual Studio generated the service reference with this at the top:
//------------------------------------------------------------------------------ // <auto-generated> // This code was generated by a tool. // // Changes to this file may cause incorrect behavior and will be lost if // the code is regenerated. // </auto-generated> //------------------------------------------------------------------------------
Is this an example of "still running into the problem?

[zhoudada]

It will be really great to have a configuration file or some mechanism to read build metadata from .csproj file. Some of my project file is from another NuGet package that I don't maintain, so it is really helpful to be able to exclude those files.

[watsonsong]

It will be really great to have a configuration file or some mechanism to read build metadata from .csproj file. Some of my project file is from another NuGet package that I don't maintain, so it is really helpful to be able to exclude those files.

Yes, I am using the unity3d so there is a problem I can not controller the files and projects. I just want to exclude some folder.

[rp0m]

100% behind this. Having to add <auto-generated /> everywhere is a problem, especially if there are specific folders that we want to ignore (e.g. EF migrations)

[watsonsong]

How about the progress about this issue?

[mavasani]

I filed https://github.com/dotnet/roslyn/issues/38674 to track a much broader analyzer bulk configuration support, which should also address the concerns raised here. I agree with @tmat than an editorconfig based configuration mechanism is possibly the best approach here.

[ssg]

@mavasani Does editorconfig support exclusion of folders? I know it supports wildcards but I have no idea how it treats folder syntax. Such as:

[src/EntityFramework]
exclude_from_blabla = true

Is this possible?

or should we have several editorconfig files scattered around for each folder?

[nahk-ivanov]

It is surprising that I have to comment on an issue dating back to 2015 in 2019. The standard MSDataSetGenerator adds:

1. <auto-generated> tag to the file header (in fact, it is the only file header it generates)
2. [global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "16.0.0.0")] attribute to every method

Yet we are still getting error CA3075: XmlTextReader instance created with insecure default settings. on the following line:

[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.CodeDom.Compiler.GeneratedCodeAttribute("System.Data.Design.TypedDataSetGenerator", "16.0.0.0")]
protected MyDataSet(global::System.Runtime.Serialization.SerializationInfo info, global::System.Runtime.Serialization.StreamingContext context) : 
    base(info, context, false) {
...
        ds.ReadXmlSchema(
--->        new global::System.Xml.XmlTextReader(
                new global::System.IO.StringReader(strSchema)));
...

Forget about user-written code that they don't want to address or a third-party NuGet package that is not compliant. We are talking MS not being compatible with MS. I'm fine either way you want to address this - fix the code-gen for data sets or allow exclusions for new FxCop analyzers, but in 4 years something could have been done, me thinks...

[mavasani]

Design based on a new editorconfig option for generated code: https://github.com/dotnet/roslyn/issues/38674#issuecomment-534621058
PR: https://github.com/dotnet/roslyn/pull/38859

[nahk-ivanov]

I can't say that I'm an expert on everything that is happening in the MSBuild area these days, but placing this configuration into something called _editorconfig_ doesn't seem like a good solution. As name implies, some might expect it to only apply to a particular editor that is used, while analyzers are ran during the build (which is not tight to any particular editor) and have to respect the configuration.

I looked briefly at the related issue and it states

In past, adding any such bulk diagnostic configuration support would have required providing new MSBuild and command line compiler switches or updating existing ones, which had a high implementation and design cost and higher risk of bugs/regressions.

While I don't fully understand what issues in particular you are referring to, I think just the fact that "compiler" is now aware of the _editorconfig_ introduces more confusion and will eventually end up in a "we don't know why, we think it's just a bad design chosen by a previous members of the team" category, like OutputPath and OutDir properties, that nobody can explain at this point.

Choosing _editorconfig_ as a dump ground for everything that we can't find a proper place for at the moment doesn't sound like a good idea long term. Did you consider adding this configuration into a _ruleset_, where you would be able to disable analysis for generated code per rule? That might be more flexible and make a little bit more sense, because you wouldn't need to modify multiple disjointed files to configure analyzers. What were the drawbacks of the _ruleset_ approach during the design discussion?

[mavasani]

@nahk-ivanov Starting VS2019 16.3, editorconfig file has already been chosen as a compiler supported format for all third party analyzer configuration - both analyzer options and diagnostic severity. You can also configure diagnostic severities in editorconfig, which will be respected on command line builds as well as IDE: https://docs.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#set-rule-severity-in-an-editorconfig-file. This allows a single file to configure all analyzer settings for the end user, instead of splitting it across ruleset and separate options file. Also note that rulesets are already on path to deprecation, it was a custom Microsoft only xml format just designed for rule severities, as opposed to the much more flexible and widely used editorconfig file format for options.

[mavasani]

Changes to the core analyzer driver to respect generated_code = true | false from editorconfig files for analyzer execution has been merged into a feature branch: https://github.com/dotnet/roslyn/pull/38859.

Compiler team would like this change to be clubbed with core compiler respecting this option for their #nullable analysis. See https://github.com/dotnet/roslyn/pull/38859#issuecomment-536793903. So assigning to the Area-Compilers to drive the feature branch features/editorconfig-generated-code for compiler changes and getting it merged back into master.

[Nitin5acc]

Hi,

Are they any examples on how to use it? We do not want code analyzer to run on certain files in a solution.

[mavasani]

You can create an .editorconfig file an mark the required files as generated (either all cs files or use some regex), with the following syntax:

# Treat all cs files in this folder as generated code
[*.cs]
generated_code = true

[beninkg]

I am not able to exclude a class file using below code in editor config. Could anyone please help.

[*.FileName.cs]
generated_code = true

[Logerfo]

@beninkg it will only be available in visual studio 16.5 preview 2.

[beninkg]

Thanks @Logerfo for the quick response.
I am using VS 16.4, can I change the severity of a rule for a specific class file ? I tried with the below code, did not work.
[*.FileName.cs]
dotnet_diagnostic.SYN.severity = warning

[beninkg]

Any leads would be greatly appreciated!

[mavasani]

Now officially documented at https://docs.microsoft.com/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#configure-generated-code

[rogerfar]

@Logerfo did this not make it in 16.6? I'm having trouble getting it to work.

When I do:

[ParserBaseListener.cs]
generated_code = true

It still generates warnings, when I do:

[ParserBaseListener.cs]
generated_code = true
dotnet_diagnostic.CS3021.severity = silent

Then warning goes away.

Even I put this in:

[*.cs]
generated_code = true

It is supposed to remove all warnings and errors, but it doesn't.

[mavasani]

Compiler warnings (CSxxxx) do not respect generated_code option, only analyzer diagnostics. There is an exception though: C# 8 nullable related compiler warnings do respect this option.

If you feel this option should be respected for all compiler warnings, feel free to file a new issue.

[kirsan31]

@mavasani I think the problem not only in compiler warnings:

V.S. 16.6.1; Microsoft.CodeAnalysis.FxCopAnalyzers 3.0.0.

[mavasani]

@kirsan31 that is a security rule, and the analyzers for most security rules register analyzing and reporting diagnostics in generates code. The assumption here is that you likely don’t want to ship security vulnerabilities in generated code.

[francisminu]

Hi All,

We have a custom roslyn analyzer with custom rules. We would like it to run on all files except a few, like, Startup.cs, Program.cs etc.,
As @rogerfar mentioned, I can get the rules not run, if I explicitly mention the rule. Please see below:
[Program.cs]
generated_code = true
dotnet_diagnostic.SYN009.severity = none

  [Startup.cs]
  generated_code = true
  dotnet_diagnostic.SYN009.severity = none

But what I am looking for is the ability to stop all warnings/erros on these files. Is this possible?

Thanks,
Minu

[mavasani]

@francisminu Which specific diagnostic IDs are you looking to suppress?

[francisminu]

These are custom rules we have developed for the different scenarios which we wanted to enforce in our development flow. So, not the microsoft ID's as such. The intent is to suppress all rules for the files Program.cs and STartUp.cs. SO not a specific id, specific id scenario works (shown above), but I want to suppress all rules, not just one.

[mavasani]

You can try the below: https://docs.microsoft.com/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#set-rule-severity-of-multiple-analyzer-rules-at-once-in-an-editorconfig-file

[Startup.cs]
dotnet_analyzer_diagnostic.severity = none

[francisminu]

That worked perfectly! Thanks Manish! Never caught my eye on this link, thanks once again :)

[qbit86]

Compiler warnings (CSxxxx) do not respect generated_code option, only analyzer diagnostics. There is an exception though: C# 8 nullable related compiler warnings do respect this option.

@mavasani
I spent quite a time figuring out why this option doesn't work.
Please mention compiler warnings explicitly in these documents:

• https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-options#exclude-generated-code
• https://docs.microsoft.com/en-us/visualstudio/code-quality/use-roslyn-analyzers?view=vs-2019#configure-generated-code