.NET analysis time during msbuild increased from 15 min to 40+ min

Hey Rouke Broersma,

I followed your steps, choose “master” branch to perform code analysis, no luck so far and still failing.

We have “Dotnet Core (3.1)” based code, using AzureDevOps pipeline and picked your build template.

As you can see here all tasks of the build pipeline

Currently we are facing, this build task is keep running - “Build task is running for more than 43 mins and getting time out”.

Let us know what to do to fix this build steps.


Hello @aarzoo2001 - could you look at the logs and see where the analysis blocks? It would be useful to add the logs here.

To be sure we find the issue, please add the sonar.verbose parameter set to true in the Prepare step, and please attach the output of analysis step step, and please attach the output of Run Code Analysis step. This will enable DEBUG logging.

This may be related to our advanced vulnerability detection rules which for large programs can sometimes take a lot of time to run. If you give us the logs, we can guide you to disable those rules until we fix the issue on our side.

Hello @Andrei_Epure: Thanks and appreciated for the reply. I tried with your hint


to get log data and was able to correct myself to read the log. Rightnow, our CI/CD pipeline is going through and completing successfully. Code analysis, code scan and code coverage is generating.

This build pipeline is taking more than 40 mins to complete the build process. Earlier we were able to finish within 15 minutes. Just to share with you about exclusion, I excluded all 3rd party and auto generated files from code analysis.


Please find the screen shot. Do you have any recommendations to optimize the Build and Test tasks?

Let us know your feedback.


Hello Aarzoo

To see what rules are taking time during build, you need to run the build with reportanalyzer :

msbuild /p:reportanalyzer=true > build.log

At the end of the build you’ll have a report similar to the one below, and this will shows us which rule is taking the most.

Total analyzer execution time: 893.913 seconds.
NOTE: Elapsed time may be less than analyzer execution time because analyzers can run concurrently.
Time (s) % Analyzer
893.913 100 SonarAnalyzer.CSharp, Version=, Culture=neutral, PublicKeyToken=c5b62af9de6d7244
448.313 50 SonarAnalyzer.Rules.CSharp.RULE_X
445.228 49 SonarAnalyzer.Rules.CSharp.RULE_Y

Please share this with us. If you feel more comfortable sending the full logs privately, I can send you a private message and you can send it there.

1 Like

Hello @Andrei_Epure: Thanks for your reply.

Earlier we have used StyleCop, it was very fast. I am going to try per your suggestion and let you know my update.

Hello @Andrei_Epure : Please send me a private message. So I can reply you there with full logs.

Hi, @aarzoo2001. StyleCop is doing style-checks. Our analyzers have far more complex logic and can also find bugs and vulnerabilities, as well as more complex code smells. This makes our analysis more computationally intensive.

I’ll send you a PM.

1 Like

Hi @Andrei_Epure: I sent you my logs. Please advise me and look forward to move forward on this topic to improve our build pipeline.


As this discussion has been moved to a private thread (to be able to share logs and more detailed private information) in the past 5 weeks, I will post here a summary of what’s been discussed:

  • @aarzoo2001 was kind enough to share with us debug logs of the analysis which is done during MSBuild. Based on this analyis, we’ve noticed that some simple rules were taking too much time, and in the last sprint we’ve improved the performance for 17 of the rules that were behaving particularly bad in their project. SonarCSharp 8.15 has been released on Monday and is expected to be deployed to :sonarcloud: this week.

  • we’ve noticed that in the pipeline shared by the customer, the “Prepare Analysis for SonarCloud” task has an impact both on the “Build” and “Run Unit Tests” tasks. Our assumption is that the Unit Test task does the build again, thus invoking the Roslyn analyzers again, instead of using the binaries created in the “Build” task. We’ve suggested to the user either to
    – run the code analysis just during the “Run unit tests” task (by moving the “Prepare Analysis…” task after the “Build” task and before the “Unit Test” task)
    – run the dotnet test using the –no-build parameter, to avoid doing a second build

We’re waiting for an answer from the user to confirm our assumption.

Kind regards,

P.S.: to demistify a bit how our product works:

The “Prepare Analysis for SonarCloud” step does the following:

  • downloads the analyzers from :sonarcloud: and installs them locally in a cache
  • creates a .ruleset file based on the Quality Profiles of :sonarcloud:
  • puts a target file in the ImportBefore folder which tells MSBuild to always use the sonar-dotnet analyzers (from the local cache) and passes the rule configuration to the analysis

Then during a build done by MSBuild our Roslyn analyzers get invoked by the Roslyn compiler framework and create the analysis output, which during the “Run Code Analysis” step is read and sent to :sonarcloud: . Also, the “Run Code Analysis” step does the clean-up of the target file added in the “Prepare…” step.

If you build your project with MSBuild in both “Build” and “Unit Tests…” tasks, then our Roslyn analyzers will get invoked in both.