Code coverage of System.Private.CoreLib is broken

[stephentoub]

According to the directions, running a test suite like System.Runtime.Tests should be able to get coverage of the code in corelib via /p:Coverage=true /p:TestRuntime=true, but while doing so does add CoreLib to the command-line, the resulting code coverage report is empty.

cc: @ViktorHofer

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

---

According to the directions, running a test suite like System.Runtime.Tests should be able to get coverage of the code in corelib via /p:Coverage=true /p:TestRuntime=true, but while doing so does add CoreLib to the command-line, the resulting code coverage report is empty.

cc: @ViktorHofer

Author:	stephentoub
Assignees:	-
Labels:	area-Infrastructure, untriaged
Milestone:	-

[danmoseley]

This has broken enough times, ideally we'd protect it with an outerloop test (just as we should protect launch and build in VS). As far as I know we have no existing example of a test that does a build, but presumably we can assume dotnet is on the path (at least we do in the build)

[trylek]

For Helix executions of CoreCLR tests Simon added provisions for passing dotnet path around for the purpose of running Crossgen2, please see here:

runtime/src/tests/run.py

Line 909 in 94641d8

os.environ["__TestDotNetCmd"] = args.dotnetcli_script_path

runtime/src/tests/Common/CLRTest.CrossGen.targets

Line 114 in ef6c694

if [ ! -z ${__TestDotNetCmd+x} ] %3B then

I guess it shouldn't be that hard to introduce a similar logic to library tests.

[ViktorHofer]

Marking as 6.0 and as a bug. Will look into this as soon as I have some cycles. Assigning to myself.