Have the SonarCloud tasks for Azure DevOps changed recently?

I am using SonarCloud with Azure DevOps to analyse 40+ Visual Studio (C#) projects, my ADO builds perform a number of tasks, including building the VS solutions in Debug configuration (with pdb symbols, etc.) followed by building the same solution in Release configuration for publishing.

I have noticed that enabling the SonarCloud Analysis can add a significant amount of time to the build, therefore in order to minimise the impact my SonarCloud analysis is enabled only for my debug build and I have achieved that until now by calling the ‘Publish Quality Gate Result’ before my Release build, you can see here the Build - Release step takes only a few seconds (and the build logs for this step shows no sonar cloud activity):

Since Monday however I have seen that SonarCloud is also scanning my Release build even if it is happening after the ‘Publish Quality Gate Result’ step and as you can see below this is adding a not insignificant delay to my builds:

So the question is, if something has changed in the behaviour of the SonarCloud tasks for Azure DevOps, how do I get these tasks to behave as they were doing before this change?

I also just ran into this as well. It looks like the new version of SonarScanner for MSBuild - 5.1.0, released 3 days ago - does not clean up properly.

After running this task all subsequent builds are now running scans. Reverting to 5.0.4 solves this issue.

1 Like

Hi there,

We made a change, yes, to enable support of concurrent builds. That has this side effect.

As a workaround, before we push a improvement on that, is to pass the p:SonarQubeTargetsImported=true as an argument in the build that is not intended to run analysis.

Depending on your setup, you can :

  • calling msbuild directly, you’d pass it on the command line e.g. msbuild /p:SonarQubeTargetsImported=true
  • call dotnet directly: dotnet build -p:SonarQubeTargetsImported=true
  • or dotnet msbuild -p:SonarQubeTargetsImported=true



Hi @mickaelcaro, setting the property as you described fixes the issue, thanks!


Hi @mickaelcaro.

Thanks for the answer - however our issue runs a bit deeper than that.

We are using the VM Scale Set Azure DevOps agents to be able to maintain a package cache on the agents and minimize network bottlenecks in our builds.

This change effectively pollutes the agents for all future builds unless we add the SonarQubeTargetsImported property to all our builds that are not running analysis. This would mean we have to add the opt-out to 50+ build jobs and that’s going to be hard to maintain.

Is there any other way to clean up after the SonarCloudPrepare task manually to avoid having to add this to all our builds? Then we can have a post-build event cleaning this up.

Thanks in advance.

Hi @rasmuskl

You can remove the .sonarqube folder that has been created by a analysis, that should solve the problem.


1 Like

Thanks. That does work. I’ll leave my yaml step here for anyone encountering the same problem.

- script: |
    rm -rf ../.sonarqube
  displayName: 'Clean up SonarCloud Scanner'
  continueOnError: true
  condition: always()

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.