-
Notifications
You must be signed in to change notification settings - Fork 386
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
Comments
You can get process ID using |
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? |
yes |
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 |
Thank you for working on the fixes, @MarcoRossignoli. |
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
andWriteHits
methods in theModuleTrackerTemplate
throw:coverlet/src/coverlet.core/Instrumentation/ModuleTrackerTemplate.cs
Line 176 in df968b8
coverlet/src/coverlet.core/Instrumentation/ModuleTrackerTemplate.cs
Line 200 in df968b8
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
The text was updated successfully, but these errors were encountered: