Problem with coverage after upgrading to .net5[WindowsDesktop app]

[abdelrahman-alfar]

C:\Users\bamboo.nuget\packages\coverlet.msbuild\3.1.0\build\coverlet.msbuild.targets(39,5): warning : [coverlet] Unable to instrument module: XXX because : AssemblyResolutionException for 'PresentationFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Try to add true to test projects or pass '/p:CopyLocalLockFileAssemblies=true' option to the 'dotnet test' command-line

After upgrading to .net5 we have a problem with coverage for one of our projects, the rest of the projects are correctly detected

I tried both suggestions but nothing happens keep receiving the above error

[abdelrahman-alfar]

any help here? its affecting our team performance at SAP

[abdelrahman-alfar]

@daveMueller could you assist here?

[daveMueller]

Could you try the solutions described in #1102? For me it feels like the same issue.

[abdelrahman-alfar]

Hi @daveMueller I tried publish but still
whats weird that I have 4 projects (one of them is the main startup file) all published to the same directory and they don't complain about this framework

I attached the logs from our CI bamboo tool

please let me know if you have other ideas/suggestions

[abdelrahman-alfar]

@daveMueller did you have the chance to check it?

[daveMueller]

Sorry really busy lately. A bit odd is that there are a lot of other exceptions in the log regarding references that can't be resolved.

Is this a WPF or WinForms project? Up to now I never worked on a desktop app with .net5. Can you share the property group of the projects .csproj file? I read somewhere that there is a UseWPF tag that automatically adds all WPF references. Should look something like this:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net5.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
</Project>

Sorry for just speculating and not being really helpful. @MarcoRossignoli @petli Do you have any idea?

[MarcoRossignoli]

Hi @abdelrahman-alfar and thx a lot @daveMueller for the help here,

After upgrading to .net5 we have a problem with coverage for one of our projects, the rest of the projects are correctly detected

Have you moved from .NET 4.x or from .NET 3.x?

TryWithCustomResolverOnDotNetCore for PresentationFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35

Looking at log this is the main error, coverlet during static instrumentation is not able to find PresentationFramework dll and so fails to instrument lib that depends on it(I think it's your missing project).

How do you build the project?
Can you verify if in your output folder the lib PresentationFramework is present(I think no)?
Are you able to create a repo, I think that do a test with a plain .NET 5 Wpf app is enough.

In past we had similar issue for asp.net, unfortunately coverlet needs to load some deps during instrumentation(Cecil works in this way) and sometimes framework/msbuild(wpf, asp.net, compilers etc...) change the output layout, sometimes they copy lib on out folder sometimes use the "machine wide" installation. I think that in .NET 5.0 for wpf we have the same scenario and maybe we'll need to add a new extension to our resolver

https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.core/Instrumentation/CecilAssemblyResolver.cs#L73 -> https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.core/Instrumentation/CecilAssemblyResolver.cs#L229

And try to load from local C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App

Another good addition to avoid to block users would be add a new option to let user to specify additional probing directory so in case of loading error as a "workaround" the user can specify where to search libs.

[abdelrahman-alfar]

@MarcoRossignoli @daveMueller thanks a lot we fixed the problem by adding a post build event which copy the dll from folder to output folder
not the best/clean way but was the best workaround I could find

[MarcoRossignoli]

I'll keep this one open, we need to improve here.

[marbel82]

@abdelrahman-alfar Can you tell me from where you copy the files? Could you show me your post-build?

I have the same problem.

Unable to instrument module: c:\SomeProject\Tests\Module.Tests\bin\Debug\net5.0-windows\Module.dll because : AssemblyResolutionException for 'PresentationFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Try to add true to test projects or pass '/p:CopyLocalLockFileAssemblies=true' option to the 'dotnet test' command-line

but when I copy PresentationFramework.dll
from c:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\5.0.0\ref\net5.0\PresentationFramework.dll
to c:\SomeProject\Tests\Module.Tests\bin\Debug\net5.0-windows\

coverlet print:

Unable to instrument module: c:\SomeProject\Tests\Module.Tests\bin\Debug\net5.0-windows\Module.dll because : Failed to resolve System.Windows.Threading.DispatcherPriority

And now I don't know what to do about it.

(I come here from FortuneN/FineCodeCoverage#188 because I use FineCodeCoverage)

[marbel82]

I charged my brain ;) and I remembered that System.Windows.Threading.DispatcherPriority is inside some assembly.

I just add WindowsBase.dll to ...\bin\Debug\net5.0-windows\ and both coverlet and Fine Code Coverage working again!

[304NotModified]

This looks like the same issue : #1231

Copying the dll from the refs folder helped multiple users. See that issue for some scripts

[MarcoRossignoli]

@304NotModified outcome is the same but in this case is slightly different...here we can fix adding well known folders like C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App\6.0.0 but not in all cases we have this info.

We should add the Windows resolver to this list https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.core/Instrumentation/CecilAssemblyResolver.cs#L75

[lg2de]

In PR #1449 I tried to fix the problem close to the idea mentioned by @MarcoRossignoli.
Would be great to get some feedback whether this fixes (also) your problem(s).