Exclude files or folder from running through the analyzers through a configuration file. #3705

Open
mantzas opened this Issue Jun 26, 2015 · 26 comments

Comments

Projects
None yet
@mantzas

mantzas commented Jun 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@lgolding

lgolding Sep 14, 2015

Contributor

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

Contributor

lgolding commented Sep 14, 2015

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

@RazPopov

This comment has been minimized.

Show comment
Hide comment
@RazPopov

RazPopov Nov 7, 2015

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

RazPopov commented Nov 7, 2015

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 srivatsn modified the milestones: Unknown, 1.2 Nov 12, 2015

@srivatsn srivatsn changed the title from Exclude files or folder from running through the analyzers to Exclude files or folder from running through the analyzers through a configuration file. Nov 24, 2015

@srivatsn

This comment has been minimized.

Show comment
Hide comment
@srivatsn

srivatsn Nov 24, 2015

Contributor

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.

Contributor

srivatsn commented Nov 24, 2015

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.

mavasani added a commit to mavasani/roslyn that referenced this issue Dec 16, 2015

Reduce noise from analyzers in generated code and allow analyzers to …
…configure generated code analysis.

1. Add a new API: AnalysisContext.ConfigureGeneratedCodeAnalysis(bool enable)
Configures analyzer callbacks + diagnostic reporting for the analyzer. Recommended for analyzer authors to always invoke this API.

2. Analyzer driver uses a heuristic to identify generated code:
  1. Symbols marked with GeneratedCodeAttribute.
  2. Files with specific extensions (see [here](http://source.roslyn.io/Microsoft.CodeAnalysis.Workspaces/R/ef3599fb042e3706.html)).
  3. Files which have a single line comment starting with  <auto-generated> at the beginning of a source file.
#3705 tracks work to allow end users to configure what is generated code for their project.

3. Driver defaults for non-configured analyzers:
  1. Always run analysis on generated code: This avoids semantic breaks for analyzers.
  2. Suppress non-critical diagnostics reported on generated code: This ensures
    1. No silent breaks for end users: Critical diagnostics marked as errors, such as banned crypto API, DeclarePublicAPI diagnostics are still reported in generated code.
    2. Reduces noise from analyzer output: addresses our primary complaint
  3. Driver defaults are liable to change in future. Analyzer authors are recommended to ConfigureGeneratedCodeAnalysis if they want a specific behavior for generated code.

Fixes #6998

@sharwell sharwell referenced this issue in DotNetAnalyzers/StyleCopAnalyzers Dec 16, 2015

Closed

C# files in the obj/ folder should be considered Auto-Generated. #1430

mavasani added a commit to mavasani/roslyn that referenced this issue Dec 17, 2015

Allow analyzers to configure generated code analysis.
1. Add a new API: AnalysisContext.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags analysisMode)
Configures analyzer callbacks + diagnostic reporting for the analyzer. Recommended for analyzer authors to always invoke this API.

2. Analyzer driver uses a heuristic to identify generated code:
  1. Symbols marked with GeneratedCodeAttribute.
  2. Files with specific extensions (see [here](http://source.roslyn.io/Microsoft.CodeAnalysis.Workspaces/R/ef3599fb042e3706.html)).
  3. Files which have a single line comment starting with <auto-generated> at the beginning of a source file.

3. Driver defaults for non-configured analyzers:
  1. Run analysis on generated code: This avoids semantic breaks for analyzers and will be guaranteed to be always enabled in future.
  2. Report all diagnostics on generated code: This will likely be changed to perform some level of default filtering after #3705 is implemented.

Fixes #6998

mavasani added a commit to mavasani/roslyn that referenced this issue Dec 18, 2015

Allow analyzers to configure generated code analysis.
1. Add a new API: AnalysisContext.ConfigureGeneratedCodeAnalysis(GeneratedCodeAnalysisFlags analysisMode)
Configures analyzer callbacks + diagnostic reporting for the analyzer. Recommended for analyzer authors to always invoke this API.

2. Analyzer driver uses a heuristic to identify generated code:
  1. Symbols marked with GeneratedCodeAttribute.
  2. Files with specific extensions (see [here](http://source.roslyn.io/Microsoft.CodeAnalysis.Workspaces/R/ef3599fb042e3706.html)).
  3. Files which have a single line comment starting with <auto-generated> at the beginning of a source file.

3. Driver defaults for non-configured analyzers:
  1. Run analysis on generated code: This avoids semantic breaks for analyzers and will be guaranteed to be always enabled in future.
  2. Report all diagnostics on generated code: This will likely be changed to perform some level of default filtering after #3705 is implemented.

Fixes #6998

@srivatsn srivatsn modified the milestones: 1.3, 1.2 Feb 4, 2016

@srivatsn srivatsn modified the milestones: 2.0 (RTM), 1.3 Apr 1, 2016

@srivatsn srivatsn modified the milestones: 2.0 (RTM), Unknown Jun 21, 2016

@codybaxter

This comment has been minimized.

Show comment
Hide comment
@codybaxter

codybaxter Aug 23, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@jake-brandt

jake-brandt Feb 15, 2017

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

jake-brandt commented Feb 15, 2017

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

@brunocunhasilva

This comment has been minimized.

Show comment
Hide comment
@brunocunhasilva

brunocunhasilva Feb 16, 2017

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

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

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

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

@normanhh3

This comment has been minimized.

Show comment
Hide comment
@normanhh3

normanhh3 Mar 15, 2017

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.)

normanhh3 commented Mar 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@sergeybykov

sergeybykov Mar 15, 2017

Member

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

Member

sergeybykov commented Mar 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jdom

jdom Mar 15, 2017

Member

@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 dotnet/orleans#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?

Member

jdom commented Mar 15, 2017

@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 dotnet/orleans#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

This comment has been minimized.

Show comment
Hide comment
@normanhh3

normanhh3 Mar 15, 2017

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?

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 comment has been minimized.

Show comment
Hide comment
@normanhh3

normanhh3 Mar 15, 2017

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

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

@bjornhellander bjornhellander referenced this issue in DotNetAnalyzers/StyleCopAnalyzers Mar 25, 2017

Closed

How ignore file by extension in visual studio code #2328

@DuncanMillard

This comment has been minimized.

Show comment
Hide comment
@DuncanMillard

DuncanMillard Jul 17, 2017

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.

DuncanMillard commented Jul 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@pavele

pavele Sep 29, 2017

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.

pavele commented Sep 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@harshil93

harshil93 Dec 19, 2017

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

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

This comment has been minimized.

Show comment
Hide comment
@normanhh3

normanhh3 Jan 11, 2018

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?

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

This comment has been minimized.

Show comment
Hide comment
@sergeybykov

sergeybykov Jan 16, 2018

Member

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

Member

sergeybykov commented Jan 16, 2018

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

@jmarolf

This comment has been minimized.

Show comment
Hide comment
@jmarolf

jmarolf Jan 16, 2018

Member

@jinujoseph owns this area

Member

jmarolf commented Jan 16, 2018

@jinujoseph owns this area

@sucaritas

This comment has been minimized.

Show comment
Hide comment
@sucaritas

sucaritas May 30, 2018

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

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

@sharwell

This comment has been minimized.

Show comment
Hide comment
@sharwell

sharwell May 30, 2018

Member

@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).

Member

sharwell commented May 30, 2018

@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).

@abogarsukov

This comment has been minimized.

Show comment
Hide comment
@abogarsukov

abogarsukov Jun 14, 2018

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).

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

This comment has been minimized.

Show comment
Hide comment
@pavele

pavele Jun 14, 2018

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

pavele commented Jun 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@bussemac

bussemac Jun 19, 2018

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.

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

This comment has been minimized.

Show comment
Hide comment
@jake-brandt

jake-brandt Jun 20, 2018

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.

jake-brandt commented Jun 20, 2018

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

This comment has been minimized.

Show comment
Hide comment
@tmat

tmat Jun 21, 2018

Member

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.

Member

tmat commented Jun 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@bussemac

bussemac Jun 21, 2018

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.

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

This comment has been minimized.

Show comment
Hide comment
@tmat

tmat Jun 21, 2018

Member

@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.

Member

tmat commented Jun 21, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment