Repository navigation
Support OpenCover output format #98
Description
OpenCover is the best format when integrating with SonarCloud/SonarQube.
Sonar supports MS VS .coverage (binary) and VS coverage xml formats as well, but these formats give unexpected line coverage metrics (see #97).
Until OpenCover is a supported output format, coverlet remains the preferred option for us,
Reacted by hmiguel, Michael Kriese, Thomas, Paolo, Jeroen van Warmerdam, Mubarak Imam, Berke Sayar, Kurai András, ladeak, Tomasz Cielecki and 7 more
Activity
josundt commentedon Feb 15, 2024
I'll give you some more details about my findings:
In the Azure DevOps pipeline after switching from Cobertura (using Publish Code Coverage Results v1 task) to MS Coverage XML (using Publish Code Coverage Results v2 task), the reported "lines covered" remained exactly the same 👍
With SonarCloud after switching from OpenCover to MS Coverage XML, the "lines covered" count dropped by 50%.
I looks like the main problem may be SonarCloud rather than the XML file written by your tool.
Still the only currently acceptable solution for us is to revert back to OpenCover and coverlet.
If your tooling had supported the OpenCover output format (and ideally also an improved way specifying output file or folder paths when using multiple files in different formats), we would have started to use Microsoft.CodeCoverage instead.
SeMuell commentedon Mar 7, 2024
After doing some analysis I totally agree that supporting OpenCover would be very beneficial. We have to stick to SonarQube and the analysis takes around 3-5 times as long with the VS coverage xml format than with OpenCover produced by coverlet.
Unfortunately, all performance benefits we gain using the Microsoft.CodeCoverage in comparison to coverlet is taken by not supporting OpenCover.
Until OpenCover is a supported output format, coverlet remains the preferred option for us as well.
martin-strecker-sonarsource commentedon May 29, 2024
Hello josundt
The issue you are seeing might be related to SonarSource/sonar-dotnet#3191. Can you provide us a reproducer? We are looking for code patterns that are not properly imported by our coverage importer. One example is methods using
yield return,but there might be more such patterns.josundt commentedon Nov 28, 2025
I just tested - as part of the .NET 10 migration of our solutions - to also migrate to the new Microsoft.Testing.Platform, following the steps in this article.
I updated global.json, added the required properties to the unit test csproj files, added the package references for Microsoft.Testing.Extensions.TrxReport and Microsoft.Testing.Extensions.CodeCoverage to support generation of the desired test execution and coverage reports, and started updating the
dotnet testarguments.Everything seemed to work perfect and I was able to complete 99% of the migration to Microsoft.Testing.Platform, except one little thing:
I suddenly had this deja vu sensation, slowly realizing that I'm being haunted by a ghost from the past, and found my way back to this issue that I reported almost 2 years ago.
I realize that the Microsoft.Tesing.Platform uses components from this repository as well, and OpenCover support has still not been prioritized.
We need to integrate our build pipelines with SonarCloud, so this practically means that I have to revert back from Microsoft.Test.Platform to VSTest - which I assume will soon become the "legacy" and later the "retired" testing platform.
Can you please consider supporting OpenCover in Microsoft.Testing.Extensions.CodeCoverage?
I should not be a very time consuming task?
fhnaseer commentedon Dec 1, 2025
Unfortunately, it is still not prioritized from our side. Scope of this is very big as it doesn't involve only adding support of creating OpenCover report. But it also adding support in Visual Studio, Visual Studio Code. And merging with different report formats.
I can suggest the following workaround for your scenario
coberturareport usingMicrosoft.Testing.Platformusing--coverage-output-format coberturahttps://github.com/microsoft/codecoverage/blob/main/samples/Algorithms/scenarios/scenario01/README.mdreportgeneratorto convert this report toOpenCoverhttps://reportgenerator.io/usageSonarCloud.Add TUnit coverage support for SonarCloud
N-Olbert commentedon Jan 20, 2026
Please note that the conversation to OpenCover requires a pro-license of reportgenerator.
Therefore, this is not a "real" workaround that is applicable for everyone.
However, if OpenCover is just required for SonarQube, one may use
--coverage-output-format xmlas mentioned above.