[coverlet] Unable to instrument module - NET 5 - Microsoft.Extensions.Logging.Abstractions

[304NotModified]

For some test projects, but not all, we get

/home/AzDevOps/.nuget/packages/coverlet.msbuild/3.1.0/build/coverlet.msbuild.targets(39,5): warning : [coverlet] Unable to instrument module: MyApi.dll because : AssemblyResolutionException for 'Microsoft.Extensions.Logging.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. Try to add to test projects or pass '/p:CopyLocalLockFileAssemblies=' option to the 'dotnet test' command-line

Tried:

• Adding <PreserveCompilationContext>true</PreserveCompilationContext> to csprojs
• Also pass /p:CopyLocalLockFileAssemblies=true to dotnet test
• Included a package reference to Microsoft.Extensions.Logging.Abstractions directly in the test projects.
• upgrade coverlet from 3.0.3 to 3.1.0

Related:

• Coverlet can't instrument module on "net5.0" target #1098 (but I can't use preview packages),
• Problem with coverage after upgrading to .net5[WindowsDesktop app] #1221 (no solution yet)
• Unable to instrument module - due to Microsoft.Extensions.DependencyInjection.Abstractions #1102 (copy to publish not possible for us)
• probably more issues

PS I hope this helps to diagnose the issue #1196. I have run more than 10 builds (with 10 tries), but all have the same issue :(

[304NotModified]

I fixed this on Azure Devops (Linux build) with a copy of the dll as follows:

This fixes two warnings:

/home/AzDevOps/.nuget/packages/coverlet.msbuild/3.1.0/build/coverlet.msbuild.targets(39,5):
 warning : [coverlet] Unable to instrument module: 
/agent/_work/1/s/Backend/MyApp.Domain.Tests/bin/Release/net5.0/MyApp.Infra.dll 
because : AssemblyResolutionException for 'Microsoft.Extensions.Logging.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. 
Try to add <PreserveCompilationContext>***</PreserveCompilationContext> to test projects </PropertyGroup> or pass '/p:CopyLocalLockFileAssemblies=***' option to the 'dotnet test' command-line 
[/agent/_work/1/s/Backend/MyApp.Domain.Tests/MyApp.Domain.Tests.csproj]

/home/AzDevOps/.nuget/packages/coverlet.msbuild/3.1.0/build/coverlet.msbuild.targets(39,5): 
warning : [coverlet] Unable to instrument module: 
/agent/_work/1/s/Backend/MyApp.Infra.Tests/bin/Release/net5.0/MyApp.Infra.dll 
because: AssemblyResolutionException for 'Microsoft.Extensions.Logging.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. 
Try to add <PreserveCompilationContext>***</PreserveCompilationContext> to test projects </PropertyGroup> or pass '/p:CopyLocalLockFileAssemblies=***' option to the 'dotnet test' command-line 
[/agent/_work/1/s/Backend/MyApp.Infra.Tests/MyApp.Infra.Tests.csproj]

Temp fix:

  - task: PowerShell@2
    displayName: 'fix - [coverlet] Unable to instrument module - Microsoft.Extensions.Logging.Abstractions'
    inputs:
      pwsh: true
      targetType: 'inline'
      script: |
        $dllToFix = "Microsoft.Extensions.Logging.Abstractions.dll"
        $from = "Backend/MyApp.Infra.Tests/bin/Release/net5.0/refs/$dllToFix"
        Copy-Item $from -Destination "Backend/MyApp.Domain.Tests/bin/Release/net5.0"
        Copy-Item $from -Destination "Backend/MyApp.Infra.Tests/bin/Release/net5.0"

it seems I have to copy the dll also one level up? (from .../net5.0/refs to .../net5.0) - does that makes any sense?

update, tested, and I really need to copy from net5.0/refs to the net5.0 folder

[MarcoRossignoli]

Hi @304NotModified thanks for reporting this. We'll take a look asap.

[MarcoRossignoli]

@304NotModified are you able to provide a repro?I have an idea of the possible problem but I need a repro to validate it.
Is it a desktop app?

[304NotModified]

It's a ASP.NET Core 5 application with multiple projects.

I'm afraid it will take some time to create a repro.

[hedasilv]

I am having the same issue:

/xxx/xxx/.nuget/packages/coverlet.msbuild/3.1.0/build/coverlet.msbuild.targets(39,5): warning:
[coverlet] Unable to instrument module: xxx/xxx/xxx/xxx/xxx.dll because: 
AssemblyResolutionException for 'Microsoft.Extensions.Logging.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. 
Try to add <PreserveCompilationContext>true</PreserveCompilationContext> to test projects </PropertyGroup> or pass '/p:CopyLocalLockFileAssemblies=true' option to the 'dotnet test' command-line

As @304NotModified pointed out it seems that coverlet msbuild cannot find the DLL under bin/Debug/.net5.0. Even though the DLL is available in bin/Debug/.net5.0/refs, things only work when I manually copy the DLL file to the parent folder,bin/Debug/.net5.0. Is it the case that coverlet needs to scan the /refs folder as well to prevent this type of issue?

[304NotModified]

If I understand it correctly,
<PreserveCompilationContext>true</PreserveCompilationContext> is creating the refs folder (or ref?), see https://docs.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#preservecompilationcontext

[MarcoRossignoli]

PreserveCompilationContext is used to emit information on deps files and help coverlet to try to resolve libs needed by Cecil.

https://github.com/MarcoRossignoli/coverlet/blob/master/src/coverlet.core/Instrumentation/CecilAssemblyResolver.cs#L173

If you're able to provide a repro I can try to improve this one.

[andrey-chernykh]

As workaround I'm using such test pipeline:

dotnet publish
cp -f ./bin/Debug/net6.0/refs/* ./bin/Debug/net6.0/
dotnet test --collect:\"XPlat Code Coverage\" -l:\"junit;LogFileName=results.xml\" -r /reports --settings coverlet.runsettings --diag /reports/test.log --no-restore

You can simplify the last string to dotnet test --collect:\"XPlat Code Coverage\" --no-restore

[304NotModified]

@MarcoRossignoli

I'm afraid that creating reproduction is hard.

I propose the following: coverlet tries to load from the refs folder, create a prerelease of coverlet, and I will be happy to test it :)

[MarcoRossignoli]

Despite the fact that use publish+ref works I feel it too much as an "hack", I prefer something more useful in every scenario.
One idea I had also in past would be add a configuration that can be used by instrumentor for probing additional default directories. Something like typesresolutionpaths where a dev can in case of issues specify a list of path where to search if default paths don't work.