0% coverage reported on netfx target
See original GitHub issueMigrating this issue over from https://github.com/tonerdo/coverlet/issues/578 comments
When running tests locally, I get correct results with netfx target on 32-bit
dotnet test tests\Blake2.Test -c Coverage -s tests\runsettings --logger trx
with the following runsettings:
<RunSettings>
<RunConfiguration>
<TargetPlatform>x86</TargetPlatform>
<DisableAppDomain>true</DisableAppDomain>
</RunConfiguration>
</RunSettings>
However, if I switch to <TargetPlatform>x64</TargetPlatform>
, I get 0% coverage.
On Azure Pipelines, I get 0% coverage under either config.
The netcore targets are correct no matter how I run.
I have tried the coverlet.collector workarounds from https://github.com/tonerdo/coverlet/blob/master/Documentation/KnowIssues.md#2-upgrade-coverletcollector-to-version--100 with no change in results.
My current config can be found here: https://github.com/saucecontrol/Blake2Fast/tree/azure-coverage
And the updated cmdline I’m using with coverlet.collectors is
dotnet test tests\Blake2.Test -c Coverage -s tests\runsettings.collector --logger trx --collect:"XPlat Code Coverage"
Issue Analytics
- State:
- Created 4 years ago
- Comments:13
Top Results From Across the Web
Coverage report says zero coverage on C#.Net Test code ...
I am trying to get the code coverage for the C# test project(Nunit test case) Using OpenCover for sonarqube analysis.
Read more >Code coverage is 0 in NET6 - SonarQube
Hi I use sonarqube developer 9.5. working with azure devops pipelines. the code coverage is not working in net6 projects in other projects ......
Read more >Code coverage not working for .net standard / .net core ...
I am getting invalid code coverage results with Microsoft.NET.Test.Sdk v15.9.0. After merging code coverage output from both the .net framework and .net ...
Read more >Generate Code Coverage Report For .NET Core & .NET ...
Console Code Coverage Report. In the previous post, I talked about how to set up a SonarQube server local to analyze the code...
Read more >How to setup your dotnet project with test coverage reporting
In this example, the results will be created in opencover format and stored at ../coverage/projects/$(MSBuildProjectName)/ path. Kinda nice… ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
It’s no problem at all. I just wanted to try it out before 3.0 lands since I had a free minute. Tried the private feed 3.0.0-preview.1, and it’s working great now. Thanks much!
I did a test and found the issue, is related to coverlet in-proc load failure, vstest plat try to load netcoreapp2.1 lib inside a netfx process and fails
TL;DR; msbuild/.net tool suffer a know issue https://github.com/tonerdo/coverlet/blob/master/Documentation/KnowIssues.md#1-vstest-stops-process-execution-earlydotnet-test So we use collector because in that way in-proc coverlet collector class is injected inside test host process and we can persist hit file. In-proc collector is integrated and communicate with vstest platform(datacollector process talk with host process and wait to kill until “they agree”).
Now the issue is that in-proc coverlet collector was written with netcoreapp2.1 tfm(I asked to vstest team why, they wrote it) so when vstest plat try to load it a lot of ref failure happens
When this happen and vstest plat kill process we suffer again of know issue above so we cannot persist hit file…and this is randomic, I mean can happen for x64 and not for x86 and vice-versa.
I did some test with a collector compiled for netstandard2.0+vstest master compiled plat and it works…btw I found also a past statement of vstest team https://github.com/tonerdo/coverlet/issues/466#issuecomment-501158913 so the past idea was support only netcoreapp, but now that we have an unsolvable issue with automatic process kill(above know issue) maybe we should change the idea…or abandon netfx(try msbuild and if you hit issue above…no solution) I’ll wait vstest team thinking.