search

coverlet-coverage / coverlet

Cross platform code coverage for .NET
MIT License
2.93k stars 385 forks source link

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

Closed daveMueller closed 1 month ago

daveMueller commented 4 months ago 
          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 https://github.com/coverlet-coverage/coverlet/issues/1231#issuecomment-1883779381

daveMueller commented 4 months ago

I start working on this.

daveMueller commented 4 months ago

@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 commented 4 months ago

Do you guys still have the issue? @MarcoRossignoli when you say that this issue is fixed in https://github.com/coverlet-coverage/coverlet/pull/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 commented 2 months ago

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

daveMueller commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

@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 commented 2 months ago

I start working on this issue...

izpavlovich commented 1 month ago

Thank you @daveMueller!

daveMueller commented 1 month ago

I've merged a small change that should fix the issue. At least it works for the repro provided here https://github.com/coverlet-coverage/coverlet/issues/1631#issuecomment-2057063145 by @rinckd. If anyone wants to test it, you can give it a try by consuming our nightly build.