Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CoreLib's coverage measurement is broken #1285

Closed
ViktorHofer opened this issue Jan 31, 2022 · 6 comments · Fixed by #1286
Closed

CoreLib's coverage measurement is broken #1285

ViktorHofer opened this issue Jan 31, 2022 · 6 comments · Fixed by #1286
Labels
blocking-users Issue is blocking some users Priority:0 Critical to the release tracking-external-issue The issue is caused by external problem - nothing we can do to fix it directly

Comments

@ViktorHofer
Copy link
Contributor

ViktorHofer commented Jan 31, 2022

After figuring out why CoreLib doesn't write the result file when being instrumented by coverlet and working around the issue, I noticed that the WriteLog and WriteHits methods in the ModuleTrackerTemplate throw:

  Unhandled exception. System.TypeLoadException: Could not load type 'System.Diagnostics.Process' from assembly 'System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'.
     at Coverlet.Core.Instrumentation.Tracker.System.Private.CoreLib_19e73ecb-b988-441a-913d-54373b41abc8.WriteLog(String)
     at Coverlet.Core.Instrumentation.Tracker.System.Private.CoreLib_19e73ecb-b988-441a-913d-54373b41abc8.UnloadModule(Object, EventArgs)
     at System.AppContext.OnProcessExit() in C:\git\runtime3\src\libraries\System.Private.CoreLib\src\System\AppContext.cs:line 88

That's because CoreLib doesn't have access to the Process type and even though those code paths aren't running by default, they are in the IL and hence the types are tried to be resolved. To unblock dotnet/runtime it would be great if these code paths that rely on Process could be changed to not include the process id.

cc @stephentoub

@ViktorHofer
Copy link
Contributor Author

cc @MarcoRossignoli

@jkotas
Copy link

jkotas commented Jan 31, 2022

You can get process ID using Environment.ProcessId in recent .NET runtimes.

@MarcoRossignoli MarcoRossignoli added the untriaged To be investigated label Jan 31, 2022
@MarcoRossignoli
Copy link
Collaborator

MarcoRossignoli commented Jan 31, 2022

We instrument and after tests can run in different runtime(after in the workflow), so I don't think that we can use #ifdef here(we build/ship for netstandard2.0).

Anyway that id is used only to avoid filename clash and are used for debugging purpose, so to not complicate too much the code we can substitute with a Guid. Is it available on CoreLib?

@MarcoRossignoli MarcoRossignoli added tracking-external-issue The issue is caused by external problem - nothing we can do to fix it directly blocking-users Issue is blocking some users Priority:0 Critical to the release and removed untriaged To be investigated labels Jan 31, 2022
@stephentoub
Copy link

we can substitute with a Guid. Is it available on CoreLib?

yes

@MarcoRossignoli
Copy link
Collaborator

We'll ship nightly build at midnight, would be great is someone tomorrow give it a try to check if this first issue is solved https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/ConsumeNightlyBuild.md

@stephentoub
Copy link

Thank you for working on the fixes, @MarcoRossignoli.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocking-users Issue is blocking some users Priority:0 Critical to the release tracking-external-issue The issue is caused by external problem - nothing we can do to fix it directly
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants