search

dotnet / vscode-csharp

Official C# support for Visual Studio Code
MIT License
2.84k stars 666 forks source link

Roslyn analyzers are being run in excluded directories #4718

Open RaZeR-RBI opened 3 years ago

RaZeR-RBI commented 3 years ago

EDIT: Issue title edited to reflect the following:

@RaZeR-RBI Sorry about that instead of generated_code = true, try setting dotnet_analyzer_diagnostic.severity = none. This should set all analyzers severity to none. (See https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-options#precedence)

That helps with hiding the warnings in the 'Problems' tab (which I've done before by specifying a filter), but the analyzers are still being run in projects located in excluded folders.

To paraphrase, the UI side of the issue can be fixed by using this option, but the performance side is, sadly, isn't solved.

Apologies if it has been asked before or I'm reporting it to a wrong repository.

My current project uses a big amount of dependencies supplied in a source form instead of NuGet packages. Solution load in VS Code takes several minutes and a lot of CPU power because of Roslyn analyzers trying to find issues in linked subprojects.

Is there a way to skip analysis in specific folders and/or projects? They still should be loaded for Intellisense to work (I can't exclude them), but I'm not particularly interested of possible issues they may contain.

Thank you very much for your hard work.

JoeRobich commented 3 years ago

You can add an .editorconfig in your projects root folder which declares the folders you do not want to analyze as generated code.

root = true

# Prevent analyzers from running in these directories
[Assets/ProCamera2D/**.cs]
generated_code = true
RaZeR-RBI commented 2 years ago

@JoeRobich Sadly, it doesn't work for me. I'm running latest omnisharp-vscode (v1.23.15) and latest omnisharp-roslyn (v1.37.15) at the time of writing.

Dependencies' code is still being analyzed, and adding the generated_code = true creates additional errors related to nullable support:

The annotation for nullable reference types should only be used in code within a '#nullable' annotations context. Auto-generated code requires an explicit '#nullable' directive in source. [WebAssembly]csharp(CS8669)

So the wildcard clearly gets picked up but since the dependencies' project options are placed in corresponding .csproj files instead of code they're ignored and it additional noise is created.

A bit of context - my project is a multi-folder workspace, and dependencies' .csproj files are referenced in the .sln located in the root of the first folder in the workspace, since they're part of a build process.

Could we please re-open this issue if it could be possibly resolved?

JoeRobich commented 2 years ago

@RaZeR-RBI Sorry about that instead of generated_code = true, try setting dotnet_analyzer_diagnostic.severity = none. This should set all analyzers severity to none. (See https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-options#precedence)

RaZeR-RBI commented 2 years ago

@RaZeR-RBI Sorry about that instead of generated_code = true, try setting dotnet_analyzer_diagnostic.severity = none. This should set all analyzers severity to none. (See https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/configuration-options#precedence)

That helps with hiding the warnings in the 'Problems' tab (which I've done before by specifying a filter), but the analyzers are still being run in projects located in excluded folders.

To paraphrase, the UI side of the issue can be fixed by using this option, but the performance side is, sadly, isn't solved.

lonix1 commented 2 years ago

@RaZeR-RBI I noticed this too. :disappointed: Maybe it's a good idea to create a new issue asking to fix this? I will upvote.

By the way I'm using this:

[*.cs]
generated_code = true
dotnet_analyzer_diagnostic.severity = none
RaZeR-RBI commented 2 years ago

@RaZeR-RBI I noticed this too. disappointed Maybe it's a good idea to create a new issue asking to fix this? I will upvote.

I think that there's a lot of issues already and we shouldn't add more burden for maintainers and other awesome people who contribute to this extension and infrastructure.

It'd be easier to re-open this one IMO.

Good to know that I'm not the only one affected by this though.

@JoeRobich

lonix1 commented 2 years ago

That's not what I meant - this issue is basically a "question", and the solution we were given addresses our problem - in theory.

But in practice it contains a bug, like you said:

To paraphrase, the UI side of the issue can be fixed by using this option, but the performance side is, sadly, isn't solved.

If we leave the bug documented in this question issue it will get lost in the noise. Unless you change the title and they reopen the issue.

I feel your pain, I have this problem all day long!

RaZeR-RBI commented 2 years ago

That's not what I meant - this issue is basically a "question", and the solution we were given addresses our problem - in theory.

But in practice it contains a bug, like you said:

To paraphrase, the UI side of the issue can be fixed by using this option, but the performance side is, sadly, isn't solved.

If we leave the bug documented in this question issue it will get lost in the noise. Unless you change the title and they reopen the issue.

I feel your pain, I have this problem all day long!

Oh, now I get it. I've edited the title and added a quote to the first post of this issue. Thanks for the idea, now we just need someone to come and re-open it :wink:

RaZeR-RBI commented 2 years ago

Since PR#2267 got reverted by PR#2296 this issue should be re-opened IMO (of course if I've not missed anything).

@JoeRobich