-
Notifications
You must be signed in to change notification settings - Fork 388
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
Code coverage stops working if assembly contains interfaces from source generators #1084
Comments
Could be similar to #482 (comment) Can you try to filter out that files with |
I've tried a few different combinations, but it doesn't seem to work. <ExcludeByFile>**/*.g.cs</ExcludeByFile> From the
|
ok thank you, I need to investigate. |
I've created a small repo here you can use to try and debug the issue: https://github.com/martincostello/coverlet-refit-repro If you clone it and run Below is screenshot showing the On my laptop the two most relevant lines are:
|
Thanks a Martin! |
@martincostello can you try with https://f.feedz.io/marcorossignoli/coverletunofficial/nuget/index.json version |
Sure - I'll take a look a bit later today. Thanks for digging into it 🙂 |
Bingo. That works! 🥳 Repro ProjectBefore
After
Internal ProjectBefore
After
|
Cool I'll release the fix asap |
I've been seeing this issue very recently whilst attempting to implement source generators (and make use of them). I've created a sample demonstrating the issue here. The sample is using coverlet.msbuild 3.0.2 in the test projects however I've also tried the 3.0.3-preview.4 with no success. |
I'm not sure what the general case fix is/should be, but the fix provided so far checks for files named to show they are generated. By convention this is by the file's name ending in |
So I'm not actually concerned whether the generated code is covered. I'm more concerned that the class/module consuming the generator is no longer covered due to the fact a source generator is being used, i.e. the consuming module doesn't show up in code coverage. |
Sure, but as in this case you control the generator, so my point was if you rename the emitted code's file name to end in It may also be that you're unintentionally emitting the code into more projects that you intended, as happened in Refit which contributed to magnifying the impact of this bug in other projects of mine: reactiveui/refit#1075 |
Ah, I see your point now. Sorry. It hadn't occurred to me that coverlet was tripping up "because" of the file name. I'll change the demo and see if 3.0.3-preview.4 fixes it. Thanks @martincostello . |
Your suggestion to change the source generated to use "source-filename.g" (the ".cs" is appended automatically by C# source generators) works using 3.0.3-preview.4 @martincostello . Thanks for your help. I know you previously said a release would be made asap, is there a rough ETA. Not rushing you, just planning is all. |
Cool, glad that's unblocked you. Rough ETA will be for Marco to answer. |
Ha sorry @martincostello . I got confused between you and Marco. :-) |
Martin is now a coverlet maintainer specialized in "alpha testing" 😄 so it's ok you ask to him(joking)
Coverlet skip by default all dlls doesn't have a corresponding local source files. In this way we don't need to ask to users to filter out not interesting code.
This week end I'll release this fix, I'm trying to add also another update but I don't know if I'll make it. |
Will this also fix the coverlet.console? @MarcoRossignoli |
Yep the engine in shared between "drivers" |
Just released |
Thanks Marco ❤️ |
From .NET 6.0 preview 2 the .NET SDK uses source generators for compiling Razor views (link). Just mentioning it here as it might over time it may cause more people to find this issue if they aren't running at least coverlet.msbuild 3.0.3. |
Hey, we're hitting a similar issue in https://github.com/OpenSAGE/OpenSAGE I'm getting:
However we're already on version 3.0.3 of the NuGet. Any ideas? |
@feliwir coverlet expects a suffix of |
@martincostello I hit a similar issue after start using the |
Is it an ASP.NET Core app that uses Razor? If so: #1140 (comment) |
No just a .NET 6 assembly library, after start using the |
You're probably hitting this issue then. The fix will be in either preview 6 or preview 7. dotnet/runtime#53275 |
@martincostello Thanks for the info |
Originally posted as reactiveui/refit#1073
Describe the bug
In a project using Refit 6.0.8 and coverlet.msbuild 3.0.2, upon updating from Refit 5.2.4, code coverage is no longer being collected for the assembly containing Refit interfaces.
Using coverlet's troubleshooting guide here, I narrowed my investigation down to this line of interest:
As there's no file on disk here, that sort of makes sense, but causes an issue as it breaks all code coverage for the project for the sake of the one interface.
I'm guessing this is something to do with the usage of source generators in Refit.
The failure then slipped through several CI jobs for Refit updates until it was noticed due to #1083.
Steps To Reproduce
Clone https://github.com/martincostello/alexa-london-travel and run
./build.ps1
.The build script will eventually output something like this:
Example build: https://github.com/martincostello/alexa-london-travel/runs/1869767942?check_suite_focus=true#step:4:78
This seems to be affecting multiple repos I have using Refit, not just this one.
Here's another example: https://github.com/martincostello/alexa-london-travel-site/runs/1870035564?check_suite_focus=true#step:4:160
Expected behavior
Assemblies containing Refit interfaces are instrumented correctly.
For the referenced repository, it should output something like this from
build.ps1
:Example build: https://github.com/martincostello/alexa-london-travel/runs/1869465349?check_suite_focus=true#step:4:80
The text was updated successfully, but these errors were encountered: