Unable to instrument module - NET 8 - Microsoft.Extensions.Logging.Abstractions

[daveMueller]

          I've referenced the latest nightly build version in my `dotnet 8` solution and I still get the error for two projects: 

Coverlet.Core.Exceptions.CecilAssemblyResolutionException: AssemblyResolutionException for 'Microsoft.Extensions.Logging.Abstractions, Version=8.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. Try to add true to test projects or pass '/p:CopyLocalLockFileAssemblies=true' option to the 'dotnet test' command-line
---> Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'Microsoft.Extensions.Logging.Abstractions, Version=8.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'
--- End of inner exception stack trace ---
at Coverlet.Core.Instrumentation.NetstandardAwareAssemblyResolver.TryWithCustomResolverOnDotNetCore(AssemblyNameReference name) in /_/src/coverlet.core/Instrumentation/CecilAssemblyResolver.cs:line 217

I have tried several workarounds, but the only one that works is copying the Microsoft.Extensions.Logging.Abstractions from the refs folder to the parent one, as suggested by @304NotModified.

Do you guys still have the issue? @MarcoRossignoli when you say that this issue is fixed in #1449, is there any specific thing to do to get rid of this issue?

Originally posted by @dovic95 in #1231 (comment)

[daveMueller]

I start working on this.

[daveMueller]

@dovic95 I can't reproduce it with our integration tests that we used in the past for this issue even after upgrading them to net8. Could you probably try to create a small repro for us? That would be really helpful to analyse the issue.

[MarcoRossignoli]

Do you guys still have the issue? @MarcoRossignoli when you say that this issue is fixed in #1449, is there any specific thing to do to get rid of this issue?

Actually should be transparent. What that fix is expected to do is to scan the machine installed frameworks and load needed assemblies from there. Microsoft.Extensions.* should be found in asp.net runtime folders.

[izpavlovich]

Hi @daveMueller. Could you please let us know if there is any progress in resolving this issue so far?

[daveMueller]

Hi @izpavlovich, I couldn't reproduce it anymore with our current release + the repro we used the last time for this issue. I couldn't spend more time into trying to reproduce it and thus there currently is not progress. If anybody could provide a simple repro for this issue I guess we could solve it really quick.

[rinckd]

Here's a simple repo that shows the issue with DependencyInjection.Abstractions: https://github.com/drinck-kbx/coverlet-dependencyinjection-abstractions8.

It can be fixed by copying the Microsoft.Extensions.DependencyInjection.Abstractions from the refs folder to the parent one, as suggested by @304NotModified, or removing the default '= ServiceLifetime.Transient' from the ServiceDescriptorExtensions.

[daveMueller]

@rinckd Thanks for that. I try to take a look as soon as possible. Really annoying issue. It feels like with every new .NET release assemblies are stored somewhere else...

[daveMueller]

I start working on this issue...

[izpavlovich]

Thank you @daveMueller!

[daveMueller]

I've merged a small change that should fix the issue. At least it works for the repro provided here #1631 (comment) by @rinckd. If anyone wants to test it, you can give it a try by consuming our nightly build.

[pfeigl]

@daveMueller is there any chance to get this with a 6.0.3 hotfix released?

We are struck by this and there doesn't seem to be any reasonable workaround for it :-(

(And just to confirm it: With the nightly, this specific problem is actually fixed).