Cobertura merge information loss

[LordSaitamaa]

Describe the bug
When merging Cobertura reports, not all data is displayed, and invalid files result from the process. The reports to be merged are provided by Coverlet. When the report generated by Coverlet is passed to the recordCoverage plugin in Jenkins, everything seems to work correctly. However, when it is a merged Cobertura report, an error appears stating "No coverage information found in the specified file."

To Reproduce
Create a new Project and an unittest project.
The unittest project contains only the following class with method:

[TestClass]
public class UnitTest1
{
	[TestMethod]
	public void TestMethod1()
	{
		Assert.IsTrue(true);
	}
}

Afterwards execute the following dotnet test command:

dotnet test -c "Release" -e:ExcludeByFile="**/Properties/*.cs" -e:CollectCoverage=true -e:CoverletOutput="../TestResults/" -e:CoverletOutputFormat="Cobertura"

Now there should be the file TestResults/coverage.net8.0.cobertura.xml with the following Result:

<?xml version="1.0" encoding="utf-8"?>
<coverage line-rate="1" branch-rate="1" version="1.9" timestamp="1702468225" lines-covered="0" lines-valid="0" branches-covered="0" branches-valid="0">
  <sources />
  <packages>
    <package name="CaseService" line-rate="1" branch-rate="1" complexity="0">
      <classes />
    </package>
  </packages>
</coverage>

Last but not least we merge the reports with the following command:
\ReportGenerator.exe -reports:"TestResults/*.xml" -targetdir:"TestResults/" -reporttypes:"Cobertura"

I currently use the net47 version but also tried it with the net8.0 one. The project is in .NET 8.0.
The output after merging looks like this:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE coverage SYSTEM "http://cobertura.sourceforge.net/xml/coverage-04.dtd">
<coverage line-rate="1" branch-rate="1" lines-covered="0" lines-valid="0" branches-covered="0" branches-valid="0" complexity="NaN" version="0" timestamp="1702471670">
  <sources />
  <packages />
</coverage>

Theres only one Reportfile to use because we currently cannot guarantee, that there will be more files in the future. Thats the reason we also merge a single file.

Versions i've used:
ReportGenerator Version 4.8.12 and 5.2.0

[Daniel Palme]

I will have a look within the next days.

[AdrianTeuscher]

We have the same issue since November 14th (ReportGenerator 5.2.0) in Azure pipeline.

[Daniel Palme]

Your example file is basically empty. It does not contain any classes:

<?xml version="1.0" encoding="utf-8"?>
<coverage line-rate="1" branch-rate="1" version="1.9" timestamp="1702468225" lines-covered="0" lines-valid="0" branches-covered="0" branches-valid="0">
  <sources />
  <packages>
    <package name="CaseService" line-rate="1" branch-rate="1" complexity="0">
      <classes />
    </package>
  </packages>
</coverage>

ReportGenerator does not evaluate <package> elements. It only analyzes <class> elements.
Therefore the resulting report does only contain an empty <packages /> element.

In a real project your coverage file will always contain some classes, so this should not be a big issue.

My question now is:
Do you have problem only with "empty" coverage files, or also when the files contains some classes?

[AdrianTeuscher]

We have a "real" project with many hundreds of classes. As mentioned, this issue appears exactly with update to version 5.2.0:

[Daniel Palme]

I can't reproduce the problem with a "real" project.
Could you please share a Cobertura file?
You can send it privately via email: [e-mail]

[AdrianTeuscher]

After looking deeper i found out, that all the cobertura files are empty after the unit test run.
Reason was the missing generation of debug symbols in our build. After setting DebugType to pdbonly it works.
Sorry for the mess...

[Daniel Palme]

@AdrianTeuscher
Thanks for taking a deeper look.

I will close this for now. Please reopen if needed.

[LordSaitamaa]

By accident, I found a few files where the coverage is below the coverage of dotnet test and some cases are incorrectly represented. This case occurs rather rarely and I have not investigated it further yet. Unfortunately, I am currently on vacation and could provide more details at the earliest next week.

Sorry for the late answer, i wasnt working this week.

I understand the sentence "In real projects this shouldnt be a problem" but:
This is a real project with a Jenkins pipeline that collects coverage (record coverage plugin). Unfortunately, this plugin cannot handle the current file and causes the pipeline to fail (status code error). These are the first changes without code in which it would of course be nice, for simplicity, if a coverage file would result that can be used (see the output of dotnet test), so that the conditions for merging (a successful pipeline) are met and a first pull request without unit tests can also be merged.