Conflicts between SonarCloud Analysis and Microsoft.CodeAnalysis.NetAnalyzers


In our Azure DevOps pipeline we build our C# application/s using dotnet build.

To date we have been using both SonarCloud and StyleCop and could see warnings from both in the output of the “dotnet build” step.

As you would expect as we are running SonarCloud we have the “Prepare Analysis Configuration” step before “dotnet build” step runs.

We are now trying to migrate over to using Microsoft.CodeAnalysis.NetAnalyzers (Roslyn Analyzer) instead of StyleCop. However, now in our “dotnet build” we are only seeing warnings from Sonarcloud and not from “Microsoft.CodeAnalysis.NetAnalyzers”.

However, if we run our build without the SonarCloud “Prepare Analysis Configuration” we then see the warnings from “Microsoft.CodeAnalysis.NetAnalyzers” in the output.

We are not trying to report the warnings from Microsoft.CodeAnalysis.NetAnalyzers to SonarCloud, we are simply trying to see the warnings in the build report within the pipeline but SonarCloud seems to prevent this.

It seems like Sonarcloud may overite Microsoft.CodeAnalysis.NetAnalyzers output or block this from running, is SonarCloud compatible with Microsoft.CodeAnalysis.NetAnalyzers or is there some configuration that we are missing?


Hi @Manraj!

I’ve created a solution to test the behavior you described but I was not able to reproduce it: GitHub - costin-zaharia-sonarsource/repro-netanalyzers-no-issue.

It contains 2 projects one is .Net Core 2.1 where I’ve added the analyzers as NuGet packages and another one for .Net 5 where the analyzers run by default.

I’m not aware of any issues or incompatibilities between our analyzers and the ones from Microsoft. I’m sure we are not intentionally blocking or overwriting anything.

Can you make a small project which reproduces the problem? This will help us to investigate further.


Thanks for replying !

So while looking through the solution you created and trying locally, We realised that we had configured our “.editorconfig” incorrectly. Once we fixed the configuration it all worked fine.