Coverlet fails to instrument F# projects that have "unknown" source (inline functions, anonymous records etc)
See original GitHub issueI have a F# solution with a web sdk api project, two shared libraries and some windows services. Coverlet sucessfully instrument and analyze one of the shared libraries and the windows services but fails to instrument the api project and one of the libraries.
I’ve seen that there are similar issues here in the repo and while this could be a duplicate of one of those I have two detail that I think sets this apart.
- it works for some projects in my solution and not for others. See below.
- I get the “unknown” file reference in the Instrumentation log entry for the failing projects none of the other issues does that. See below.
I’ve tested with all three variants of coverlet 3.0.3: msbuild, collector and console and all three give the same result. Inspecting the logs I see this for the failed instrumentations:
Unsuccessful library and unsuccessful api project,
[coverlet] Unable to instrument module: C:\myproject\src\tests\bin\Debug\net5.0\coreLibA.dll, pdb without local source files, [C:\myproject\src\coreLibA\unknown]
[coverlet] Unable to instrument module: C:\myproject\src\tests\bin\Debug\net5.0\myapi.dll, pdb without local source files, [C:\myproject\src\api\unknown]
Things I’ve tried and checked:
- Creating a new solution with same kind of projects - unable to reproduce.
- Does changing the name of the assembly with the <AssemblyName> property have any impact? - No, i have one changed and one unchanged assembly name that works and one changed and one unchanged that doesn’t work.
I have two questions:
- What else can I do to find what the significant difference is between the projects that work and those that don’t?
- What is the significance of the strange “unknown” file reference at the end that I get
[C:\myproject\src\api\unknown]
. The word “unknown” is not present in the coverlet repo so I assume it comes from something external to coverlet.
Issue Analytics
- State:
- Created 2 years ago
- Comments:25
Top Results From Across the Web
Coverlet fails to instrument F# projects that have "unknown" ...
Coverlet fails to instrument F# projects that have "unknown" source (inline functions, anonymous records etc)
Read more >Hey Rustaceans! Got an easy question? Ask here (12/2022)!
I have some experience with basic languages like python, C++ etc. I want to make an e-commerce website using rust so if anyone...
Read more >PeopleCode built-in functions and language constructs
Use the BulkInsertField function to insert a source field into records and pages in a project if and only if the model field...
Read more >C++ Core Guidelines
The C++ Core Guidelines are a set of tried-and-true guidelines, rules, and best practices about coding in C++.
Read more >JOURNAL OF FEDERAL LAW AND PRACTICE Volume 70 ...
critical role in punishing and deterring fraud, as well as in returning money to the Medicare Trust Funds and other health-care programs.
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
Problem reproduction repo up: https://github.com/da9l/coverletWithAnonymousRecords In the repo there are two libs and one test project. One of the libs contains an anonymous record and the other one don’t. The one with AR does not show up in the coverlet analysis.
I deleted every old version of
coverlet.collecter.dll
from my computer, removed allbin
/obj
folders and rebuilt everything from scratch; and the error is gone now. I also went throught my PDB’s and the changes in #1165 and it seems like everything should be OK. AFAICT updating the version ofcoverlet.collector
inpaket.dependencies
and restoring was not enough. @daveMueller thanks anyway.