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.