AzureDevops 'Run Code Analysis' SonarCloud failure

We’ve had a reasonably stable Azure Devops pipeline for months, and haven’t had to change it recently until this morning. All I have done is change the solution name the pipeline refers to - and now straight away this has broken the ‘Run Code Analysis’ task ?

I reverted the change to my pipeline to make sure it wasn’t me - and it’s still broken.Even though I have reverted the changes - I notice the Sonar Scanner has upgraded itself to 1.6.1 from 1.6.0.

I’ve downloaded the Code Coverage file generated in the previous steps and it looks fine. I can export to xml also…

Going back through the history of this mornings builds - it literally seems to break once the Sonar Scanner had been updated from 1.6.0 to 1.6.1?

Any idea what’s causing this?

Is there a way of reverting back to 1.6.0 for now until the issue is resolved as we heavily use SonarCloud on a daily basis to check Code Coverage?


Looks like the repo got updated a few hours ago?

Apologies for the inconvenience. Yes, we did publish a bug-fix version (v1.6.1) of the extension yesterday that embedded a newer version of the Scanner for MSBuild. Unfortunately, it’s not possible in an Azure DevOps pipeline to specify a particular version of a task; we’ll have to publish a new version of the extension that contains a fix or reverts back to the older version of the Scanner for MSBuild.

The new version of the extension worked on the multiple different configurations we tested it on. Could you provide us with some more information to help us work out why the coverage files are not being converted in your build please?

  • please provide the debug output for that section of the “Run Code Analysis” task. The easiest way to get the debug output is to run the build definition with system.debug=true.
  • are you using a Microsoft-hosted agent or a self-hosted agent? If Microsoft-hosted, which agent pool?
  • which code coverage tool are you using?
  • are you building .NET Fx or .NET Core projects, and are you running the tests using “dotnet test” or the VSTest task? If you are using the .VSTest task, which Test Platform Version are you targeting?

FYI the process for converting the .coverage files hasn’t changed. The only difference is that the “Run Code Analysis” task is now looking in a secondary location for coverage files if it did not find any coverage files in the normal location.

Looking at the log output, the task didn’t find the coverage using the previous mechanism so it’s searching the secondary location and finding a coverage file there. I don’t understand how the build would have been able to show coverage in SonarCloud previously if it wasn’t finding a coverage file using the original search method. Are you explicitly passing additional parameters to the “Prepare analysis” task to configure the location of the tests reports, and if so what parameters are you passing?


Note that in the meantime, we have reverted the change by releasing a version 1.6.2.

Hi Yes I noticed whilst we are still getting the error in our pipelines - we can in fact see our coverage again?

Thanks for your help.

I will be in touch shortly with a full reply about the questions Duncan raised…

I’ve attached a log for one of the failing runs - it’s stopped failing now which I am guessing is down to you guys :slight_smile:

Log.txt (23.5 KB)

Agent: Hosted Agent
Pool: Hosted VS2017

We use a powershell script that takes the coverage file taken from the test results (just the standard .net core testing task with the --collect:“Code Coverage” option turned on)

We are running in .Net Core and use the dotnet test…

Here is our prepare analysis config

Hope this helps

If you need me to help in anyway let me know!


Hi @jasonpdoherty

@duncanp will certainly have a look, but only after next week. Thanks for the logs, it will certainly be useful.

Hi Jason,

We are in the process of qualifying a fix for that, allowing you to provide your own coveragexml files along with the reportsPaths property filled, thus this one will be considered and uploaded to SonarCloud.

We will let you know when it will be available.