[BUG] Missing code coverage when there is logic that sets a default value for a parameter of a specific type

[CristianBordeanFortech]

Describe the bug
There is no code coverage in a Web project when there is logic that sets the default value for a parameter of type Microsoft.Extensions.DependencyInjection.ServiceLifetime.

To Reproduce
MissingCoverage.zip
I've attached a sample project where the issue can be reproduced. By removing the serviceLifetime default value from CheckLifetime code coverage works.

Expected behavior
To see project code coverage.

Actual behavior
The code coverage is simply missing in the project, there is no error, the test gets executed.

Configuration (please complete the following information):
The project is written in .NET 6, the tests project has coverlet.collector 6.0.0. My machine is running on Windows 11. The issue is not specific to this configurations.

Additional context
The code that breaks coverage doesn't needs to be used. I've also tried switching to other types and was not able to reproduce this.

[daveMueller]

Thanks for reporting and thanks for the repro. When enabling the log it can be seen that it is the same issue as #1102. The assembly Microsoft.Extensions.DependencyInjection.Abstractions, Version=6.0.0.0, can't be resolved.

To get coverage with the collector in your repro I had to do two things. Add PreserveCompilationContext to the assembly under test.

MissingCoverage.Host.csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
	<PropertyGroup>
            <TargetFramework>net6.0</TargetFramework>
	    <PreserveCompilationContext>true</PreserveCompilationContext>
        </PropertyGroup>
</Project>

And additionally upgrade to coverlet.collector 6.0.1 as we made some improvements to the assembly resolver in this version.

[CristianBordeanFortech]

@daveMueller, thanks for having a look in such a short time and providing a solution. What you suggested worked.
The one thing that I don't understand though is why there is a difference if serviceLifetime has a default value or not. If that assembly causes the issue there shouldn't be any difference, no?

[NickBranstein]

@daveMueller, thanks for having a look in such a short time and providing a solution. What you suggested worked. The one thing that I don't understand though is why there is a difference if serviceLifetime has a default value or not. If that assembly causes the issue there shouldn't be any difference, no?

Thanks so much for this - you saved us a ton of headaches. Interestingly enough this works fine for us on 6.0.0 when removing that default parameter. Interesting tidbit, this didn't start happening for us until we upgraded to dotnet 8.