Coverlet code coverage not working with MVC/Razor applications targeting ASP.NET 6 preview 3+

[martincostello]

In .NET 6 preview 3, the Razor compiler was changed to use a Roslyn source generator instead of compiling a separate .Views assembly (announcement).

This causes coverlet to be unable to instrument the application's assembly due to seemingly missing source files emitted into the assembly/PDB for the views:

[coverlet] Unable to instrument module: C:\Coding\martincostello\api\tests\API.Tests\bin\debug\net6.0\API.dll, pdb without local source files, [C:\Coding\martincostello\api\src\API\Microsoft.NET.Sdk.Razor.SourceGenerators\Microsoft.NET.Sdk.Razor.SourceGenerators.RazorSourceGenerator\_Views_Docs_Index.cshtml.cs]

This Pull Request shows the missing coverage in the GitHub Actions build logs.

At first I thought this might have been caused by dotnet/sdk#16777, but having updated to a nightly build of the preview 4 SDK containing the fix for that issue to verify that (6.0.100-preview.4.21210.1), code coverage is still not reported.

I'm not sure if this is an SDK issue (say missing .g.cs suffixes like fixed by dotnet/sdk#16777), a coverlet issue, or both, so I'm opening this issue here and have also opened coverlet-coverage/coverlet#1140 reporting the same problem.

To replicate the issue and generate an MSBuild binary log file with the coverlet logging present, run the following commands:

git clone https://github.com/martincostello/api.git martincostello-api
cd martincostello-api
git checkout 39867b25cc6faccaa85a3091c2a8dfa58dad6975
./build.ps1 -SkipTests
dotnet test tests/API.Tests -c debug -verbosity:diagnostic -bl:msbuild.binlog -noconsolelogger

You can then open the msbuild.binlog file in MSBuild Structured Log Viewer and search for [coverlet] to find the log message.

/cc @captainsafia @pranavkm

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!

[martincostello]

I guess this is just currently low-priority. It still repros as of preview 4.

[captainsafia]

@martincostello We recently added a UserRazorSourceGenerator build flag that you can disable to bring back the old behavior in the meanwhile. I haven't had the chance to investigate this to figure out what might be wrong but the flag should help you work around it for now.

[martincostello]

Cool, thanks @captainsafia - I'll give that a try when the preview.5 build lands.

[captainsafia]

Yep -- I think the internal _UseRazorSourceGenerator build property should be available in preview4 if you want to use that. Not that it was renamed to the public version in preview5 and beyond so you'll have to update as necessary.

[martincostello]

Looks like dotnet/sdk#17492 didn't make it into the public preview.4 build, so the override of the internal/private property gets overridden back to true. Will just use the public override once preview.5 is out 👍

[captainsafia]

@martincostello Ah bummber! My bad for the misinfo. Time moves quickly and I lose track of what shipped in what. 😄

[martincostello]

FYI I've gotten _UseRazorSourceGenerator working as a workaround for this in preview 5.