Coverlet: Coverlet assumes coverage of 3rd party files with embedded ppdb

Created on 26 Jun 2019  路  19Comments  路  Source: coverlet-coverage/coverlet

Hi,

Looking here: https://dev.azure.com/dotnet/ReactiveUI/_build/results?buildId=18689&view=codecoverage-tab

I see that it's trying to measure coverage of System.Reactive. Rx has embedded ppdb's in it. I'm assuming Coverlet assumes to measure coverage if it finds a pdb, but many 3rd party libraries have embedded ones.

Is there a way to better detect this so people don't have to have large amounts of config by defualt?

enhancement up-for-grabs

Most helpful comment

@aalmada just open a PR to solve the issue https://github.com/tonerdo/coverlet/pull/510 the idea si to skip instrumentation for modules with embedded pdb without local source available.

All 19 comments

My point is that I don't want it to instrument/include coverage for those third parties by default.

Mmm how does coverlet know that are "third parties"?
I mean at the moment coverlet analyze dlls, it doesn't use csproj metadata to chose what instrument(as you already know for that we provide filters).

Maybe there is a way to filter out 0% asm from ReportGenerator cc: @danielpalme

Is there a way for it to detect if the source files are present for it (based on the pdb data)? That could be the most fool-proof method.

You could get the source documents from the PDB: https://github.com/NuGetPackageExplorer/NuGetPackageExplorer/blob/master/Core/AssemblyMetadata/AssemblyDebugParser.cs#L129

And determine if they exist.

We could take a look...maybe could be some interaction with source link switch cc: @tonerdo

Where in the code base does that processing happen?

Thanks. For this option, I don't think sourcelink is relevant. That provides a path to map the local file to some other web location. In this case, all we need to check is if the local file exists. I think all we need is to gather the document paths and skip outputing any coverage data for those. I think it's okay to leave them instrumented. Outputting/suppressing data for missing files could be an option (with the default to suppress).

That provides a path to map the local file to some other web location

I thought that with embedded pdb+sourcelink we can generate report also for third party lib, but I didn't go deep on that part of coverlet yet so my idea was likely wrong.

I thought that with embedded pdb+sourcelink we can generate report also for third party lib, but I didn't go deep on that part of coverlet yet so my idea was likely wrong.

In theory you could, if you downloaded the source files from sourcelink. That said, I would expect that most people are interested in coverage of their own code, not of external things. That's why I'd suggest that be the default, and possibly enable coverage of external code as an option.

@tonerdo a pair of question to go on with this
1) You wrote source link integration...is your original idea allow to generate report also for 3d party libs?
I mean report generator download file from web thanks to https://github.com/tonerdo/coverlet/blob/5a139b200f7bf51c21660b93f41906f4571c971b/src/coverlet.core/Coverage.cs#L246
2) What do you think about the idea of

Outputting/suppressing data for missing files could be an option (with the default to suppress).

Maybe there is a way to filter out 0% asm from ReportGenerator cc: @danielpalme

You can specify filters in ReportGenerator, but you have to supply the name of the assembly.
There is no way to filter based on coverage.

@MarcoRossignoli @onovotny

You wrote source link integration...is your original idea allow to generate report also for 3d party libs?
I mean report generator download file from web thanks to

Not really. It was meant to allow coverage reports to always link to the specific version of the source code.

Outputting/suppressing data for missing files could be an option (with the default to suppress)

This is actually a good idea. Although I'll take it a step further and not instrument to begin with

We'll need to update this method https://github.com/tonerdo/coverlet/blob/d5d0a0b59c4d52ab759711e2e0a5fddab7ef87d7/src/coverlet.core/Helpers/InstrumentationHelper.cs#L25 to check if a document in the PDB is present on the local machine

I'm happy to work on it this weekend

Thank's Toni!

@tonerdo any luck here?

We're seeing users get confused by this leading to unexpected errors: https://github.com/dotnet/reactive/issues/984. Rx/Ix has embedded ppdb's, which is what's tripping up that person.

I can find in the coverage report when it considers unwanted 3rd party libraries but, in this case, no report was being generated. I was getting the following cryptic error message:

_System.IO.FileLoadException : Could not load file or assembly 'System.Interactive, Version=4.0.0.0, Culture=neutral, PublicKeyToken=94bc3704cddfc263' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)_

It would be great if, at least, a friendlier message was shown warning that a signed assembly was found and that it cannot be handled by coverlet.

Thanks for the amazing work!

@aalmada just open a PR to solve the issue https://github.com/tonerdo/coverlet/pull/510 the idea si to skip instrumentation for modules with embedded pdb without local source available.

@onovotny can you try with the latest nightly build to see if things work as expected?

Was this page helpful?
0 / 5 - 0 ratings