[BUG] TypeInitializationException when targeting .NET Framework

[martincostello]

Describe the bug

When targeting net481 with coverlet.msbuild@8.0.0, a TypeInitializationException is thrown when tests are run.

To Reproduce

1. Clone martincostello/sqllocaldb@369c323 on a Windows machine
2. Run build.ps1 from the root of the repository.

Expected behavior

Tests pass and coverage is collected.

Actual behavior

Error: System.TypeInitializationException : The type initializer for 'Coverlet.Core.Instrumentation.Tracker.MartinCostello.SqlLocalDb_d1a4020d-c271-494f-94d5-55a151367e7c' threw an exception.
---- System.IO.FileNotFoundException : Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

  Failed MartinCostello.SqlLocalDb.Interop.WindowsRegistryTests.OpenSubKey_Returns_Null_If_Key_Not_Found [152 ms]
  Error Message:
   System.TypeInitializationException : The type initializer for 'Coverlet.Core.Instrumentation.Tracker.MartinCostello.SqlLocalDb_d1a4020d-c271-494f-94d5-55a151367e7c' threw an exception.
---- System.IO.FileNotFoundException : Could not load file or assembly 'System.Runtime, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
  Stack Trace:
     at Coverlet.Core.Instrumentation.Tracker.MartinCostello.SqlLocalDb_d1a4020d-c271-494f-94d5-55a151367e7c.RecordHit(Int32 )
   at MartinCostello.SqlLocalDb.Interop.WindowsRegistry.OpenSubKey(String keyName) in /_/src/SqlLocalDb/Interop/WindowsRegistry.cs:line 18
   at MartinCostello.SqlLocalDb.Interop.WindowsRegistryTests.OpenSubKey_Returns_Null_If_Key_Not_Found() in /_/tests/SqlLocalDb.Tests/Interop/WindowsRegistryTests.cs:line 18
----- Inner Stack Trace -----
   at Coverlet.Core.Instrumentation.Tracker.MartinCostello.SqlLocalDb_d1a4020d-c271-494f-94d5-55a151367e7c..cctor()

Configuration (please complete the following information):

Please provide more information on your .NET configuration:

• Which coverlet package (collector, console, msbuild, ...) and version was used? coverlet.msbuild@8.0.0
• Which version of .NET is the code running on? net481
• What OS and version, and what distro if applicable? Windows 10
• What is the architecture (x64, x86, ARM, ARM64)? x64
• Do you know whether it is specific to that configuration? Yes

Additional context

None.

[jaredpar]

Seeing the same in my projects jaredpar/complog#329

[Bertk]

Thank you for the feedback. We’ll update the README.md to include the required .NET 8.0 runtime for the test environment. Other target framework versions can still be used for the test projects.

[martincostello]

So if I'm understanding correctly, .NET Framework support has been completely dropped and we have to find a completely different code coverage solution now?

[Bertk]

Sorry, but this is not correct. Coverlet is designed for .NET Core projects and also supports the .NET Framework. We also have a .NET Framework test project for integration testing.

https://github.com/coverlet-coverage/coverlet/blob/master/test/coverlet.tests.projectsample.netframework/coverlet.tests.projectsample.netframework.csproj

https://dotnet.microsoft.com/en-us/platform/support/policy
https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-framework

[martincostello]

OK, so I'm confused then.

You reply makes it sound like a docs issue regarding the minimum supported version, not a bug, but my test project multi-targets with net10.0 and net481.

I don't see how that doesn't meet the minimum runtime requirement?

netfx support just seems broken in 8.0.0.

[Bertk]

Kindly install the .NET 8.0 SDK on your test system and execute the tests without changing the target framework. Coverlet depends on the .NET 8.0 base class libraries to run successfully.

[martincostello]

So it needs exactly .NET 8, and doesn't work if only .NET 9 or 10 installed? That's particularly confusing for .NET Framework support and when it works fine with only the .NET 10 SDK installed on Linux and macOS.

If that's the case, that's a bug IMHO as it should work with all currently supported versions of .NET.