Update:
As per the release to Azure Devops for Sprint 150
When publishing code coverage reports, you no longer need to specify HTML files.
Therefore, the script in my illustration no longer needs to use the report generator tool directly to create the html report, and when publishing the coverage results, the directory containing those html reports doesn't need to be specified.
Edit:
The trick I've found for getting the coverage results from a .Net Framework project to show up on the Code Coverage tab is in the same line of thought to your linked article.
- Don't run tests with the VS Test Task in Azure
- Install the Report Generator and Coverlet tools directly
- Use dotnet-vstest command for running tests through Coverlet
- Publish reports generated with Report Generator and Cobertura format coverage results
Don't use the VS Test Task
Running this task will allow you to collect coverage with a simple checkbox, but you then surrender your opportunity to provide the content for the Code Coverage Tab
Install tools directly
Use a Powershell task (or similar) to install the Coverlet and Report Generator tools directly. This allows you to use them on projects that are not .Net Core.
"install tools:"
&dotnet tool install dotnet-reportgenerator-globaltool --tool-path . --version 4.0.12
&dotnet tool install coverlet.console --tool-path . --version 1.4.1
Use dotnet vstest through coverlet
It's my understanding that dotnet test doesn't play nice with .Net Framework projects/assemblies. However, we can still use the dotnet command, which we know will be on the agent machine, but we need to use it as a mechanism to get to the vstest.console.exe.
The Coverlet tool, as mentioned in the article you linked, will output coverage results in Cobertura format if you tell it to do so.
&$coverlet $unitTestFile.FullName --target "dotnet" --targetargs "vstest $($unitTestFile.FullName) --logger:trx" --format "cobertura"
Publish results
Complete script sample
note: this script is pretty rough, so use it as a thought exercise for your individual situation.
"install tools:"
&dotnet tool install dotnet-reportgenerator-globaltool --tool-path . --version 4.0.12
&dotnet tool install coverlet.console --tool-path . --version 1.4.1
"`nmake reports dir:"
mkdir .
eports
"`nrun tests:"
$unitTestFile = gci -Recurse | ?{ $_.FullName -like "*bin*UnitTestProject2.dll" }
Write-Host "`$unitTestFile value: $unitTestFile"
$coverlet = "$pwdcoverlet.exe"
"calling $coverlet for $($unitTestFile.FullName)"
&$coverlet $unitTestFile.FullName --target "dotnet" --targetargs "vstest $($unitTestFile.FullName) --logger:trx" --format "cobertura"
"`ngenerate report(s)"
gci -Recurse |
?{ $_.Name -eq "coverage.cobertura.xml" } |
%{ &"$pwd
eportgenerator.exe" "-reports:$($_.FullName)" "-targetdir:reports" "-reporttypes:HTMLInline;HTMLChart" }
If you're struggling to figure out the escaping of quotes and such with the Coverlet command, YOU ARE NOT ALONE. I used the echoargs commandlet from PSCX more times than I care to admit so I could see what was actually getting provided to the .exe calls I was making.
The Results!!
...because that's really what matters
Original Answer:
Because of the way the linked article you mentioned is installing and using the report generator global tool I would think you can still follow those guidelines for creating the HTML inline and chart report types.
I'm not sure what is meant or how it works when the article says,
The point is the reporttypes: Use HTMLInLine for enabling the output on the Azure DevOps page. Azure DevOps Coverage page show index.html on the web.
I'm understanding that you can use the tool to create the HTML report from the .xml coverage results, and then publish the coverage results and report together with the Publish Code Coverage task.
So it seems all you need is to have an .xml format of the .coverage tool.
I didn't get it working in straight powershell, but you could follow the instructions from the Report Generator documentation to write a C# utility to access the Coverage.Analysis library.
