SonarScanner should not try to convert xml coverage data for C#

SonarQube Server / Community Build
1

  • SonarQube Server v2026.1

  • Azure DevOps Pipeline with SonarQube*@8 tasks

When analyzing a build which runs

dotnet test MyProject --collect "Code Coverage;Format=cobertura"

I get the output with error

Attempting to locate a test results (.trx) file...
Looking for TRX files in: E:\agent\_work\3\TestResults, E:\agent\_work\3\s\TestResults
The following test results files were found: E:\agent\_work\3\s\TestResults\z003s6am_server_2026-07-21_08_14_15_net10.0.trx
The following code coverage attachments were found from the trx files: E:\agent\_work\3\s\TestResults\user_server_2026-07-21_08_14_15\In\server\user_server_2026-07-21.08_15_01.xml
##[error]  Failed to convert the binary code coverage reports to XML. No code coverage information will be uploaded to the server (SonarQube/SonarCloud).

Of course, because the coverage data already is xml, so no need to convert it. The coverage is also shown correctly in SonarQube, but the logged error of the SonarQubeAnalyze@8 task is very annoying.

If I simply run with --collect "Code Coverage", the binary files are converted and no error is logged:

Looking for TRX files in: D:\agent\_work\1\TestResults, D:\agent\_work\1\s\TestResults
The following test results files were found: D:\agent\_work\1\s\TestResults\user_server_2026-07-21_08_54_00_net10.0.trx
Absolute path to coverage file: D:\gandalf\_work\1\s\TestResults\user_server_2026-07-21_08_54_00\In\server\user_server_2026-07-21.08_54_50.coverage
The following code coverage attachments were found from the trx files: D:\gandalf\_work\1\s\TestResults\user_server_2026-07-21_08_54_00\In\server\user_server_2026-07-21.08_54_50.coverage
Not using the fallback mechanism to detect binary coverage files.
Converting coverage file 'D:\agent\_work\1\s\TestResults\user_server_2026-07-21_08_54_00\In\server\user_server_2026-07-21.08_54_50.coverage' to 'D:\agent\_work\1\s\TestResults\user_server_2026-07-21_08_54_00\In\server\user_server_2026-07-21.08_54_50.coveragexml'.

But I don’t want to use the .coverage format, as is also suggested by .NET test coverage | SonarQube Server | Sonar Documentation .

2

Hey @carlossus, it seems like the scanner is assuming that the trx attachment will be a native binary .coverage report, and it can’t deal with the already-converted cobertura xml report. I’m going to flag this for the team so that they can check if it’s a bug or a missing feature.

As a workaround, you could stop attaching a Cobertura report to the trx and, instead, generate coverage as a standalone report and configure its path explicitly. This is in line with what we document. For example, use dotnet-coverage collect to generate Visual Studio coverage XML and set sonar.cs.vscoveragexml.reportsPaths during the SonarQube prepare step.

4

Hi @andres,

thanks for the reply.

Turned out for me to be nontrivial to use dotnet coverage, because one must know a lot of things which don’t seem to be documented anywhere (at least I haven’t found the relevant information): If you have a single .runsettings file with test parameters and coverage settings, then dotnet test always collect coverage information. I had to split into two settings files to fix this (`dotnet test` always collect code coverage if datacollector is defined in `.runsettings` file · Issue #10135 · microsoft/testfx · GitHub) like

dotnet coverage collect --settings Coverage.json -- dotnet test --settings .runsettings
6

Hello @carlossus,

Thanks for the detailed report — I confirm it’s a bug in SonarScanner for .NET.
I’ve added a ticket to our backlog to fix it (internal only). No ETA yet, but we’ll update this thread once it’s fixed.

Thanks again for flagging this!

Best Regards
Mary