When publishing test project "CopyCoverletDataCollectorFiles" overwrites project assemblies

[danielp37]

We have several test projects that we run "dotnet publish" to create an artifact to be run on a different machine from the build machine and when doing this we would get assembly binding errors like:

System.IO.FileLoadException : Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I found that when the project was built with dotnet build, it would have the correct version of System.Threading.Tasks.Extensions but when dotnet publish was run on the project, the System.Threading.Tasks.Extensions would be replaced with an older version (Version 4.0.0.0).

I traced this down to a build target here:

https://github.com/coverlet-coverage/coverlet/blob/bfaa38f761b0b8e88661e364e0a49c559021003b/src/coverlet.collector/build/netstandard1.0/coverlet.collector.targets

That copies all the assemblies in the build\netstandard1.0 directory to the publish directory. I'm not sure why this is done but many of the assemblies in this directory are assemblies that the project itself might also have and this copy ends up resulting in older assemblies being copied into the directory and autogeneratebindingredirects will have created binding redirects for the original assemblies and thus the tests will fail when trying to load these assemblies.

[MarcoRossignoli]

You're publishing tests project and test on different machine which what command(can you attach command line to understand your workflow). Is it .NET Framework right(not .NET Core)?

[mcm2020]

Experiencing this as well. This is the command we're using:
dotnet publish "$csproj" --configuration Release -nodeReuse:false --verbosity normal --output "$output_dir"

Coverlet is overwriting *.dll's of dependencies that it shares with "$csproj". For example, our "$csproj" has a dependency on Microsoft.NET.Test.Sdk 16.6.1. One of the dll's in the sdk is Microsoft.VisualStudio.TestPlatform.CoreUtilities, and we need that version to be at least 16.6.1, because older versions are incompatible with net5's version of dotnet test (this was discussed a bit here: #1042). However, coverlet (we're using latest nuget -- 3.0.3 as of now) is overwriting the CoreUtilities.dll to the version it uses, which is older and incompatible with net5 dotnet test

[ta264]

I am having the same issue.

The documentation states:

dotnet publish
...
... -> C:\project\bin\Debug\netcoreapp3.0\testdll.dll
... -> C:\project\bin\Debug\netcoreapp3.0\publish
...
dotnet vstest C:\project\bin\Debug\netcoreapp3.0\publish\testdll.dll --collect:"XPlat Code Coverage"
As you can see in case of vstest verb you must publish project before.

But when you publish a project that references coverlet.collector, all the contents of build/netstandard1.0 get copied into the output directory. As mentioned above, this includes commonly used dependencies such as Microsoft.Extensions.DependencyInjection.dll and breaks our project completely.

We are building and testing like this:

dotnet publish src/Radarr.sln
dotnet test Radarr.Common.Test.dll --settings:"src/coverlet.runsettings" --results-directory:./CoverageResults

(i.e. we test existing assemblies using dotnet test since dotnet vstest has been superseeded. In practice there are many more dlls on the dotnet test command line)

[Osypchuk]

Workaround which worked for me: downgrade coverlet.collector to version 1.3.0

[MarcoRossignoli]

Hi all!

Can someone dogfood this preview version with the fix attempt and tell me if it works?
https://f.feedz.io/marcorossignoli/coverletunofficial/nuget/index.json version 3.1.1-preview.10

[Digiman]

I am using version of coverlet.collector 3.1.2 for .NET 6 project (target framework -> net6.0) and locally and even on GitHub Actions it's not working.

So every time problem with rewriting libraries:

1. Microsoft.Extensions.DependencyInjection.dll
2. Microsoft.Extensions.DependencyModel.dll

It's really strange because on Windows build it's not working for publishing the web service. But in Docker build with Linux image application works as expected and starts from container without any issues.

Packages installed for Test project:
<PackageReference Include="coverlet.collector" Version="3.1.2"> <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets> <PrivateAssets>all</PrivateAssets> </PackageReference>

So i am not sure that this issue resolved or need to do something else, configure or tune the build and publish logic.

Thanks.

[osiwshaya]

Hi all,

I have an application targeting net 6.0. We are including coverlet.collector 3.1.2 as a package reference to our test projects. We are also experiencing problems during dotnet publish where Microsoft.Extensions.DependencyInjection.dll and Microsoft.Extensions.DependencyInjection.Abstractions.dll overwrite our desired versions of these assemblies.

This thread implies that this was fixed as part of #1243

Looking at the PR, I see the addition to the targets file:

As mentioned, out of the box, this is still clobbering these dependencies with older version that are within the nuget folder.

Is there something else that needs to be done to stop this behavior from happening? Previous responses in this thread imply that it is fixed out of the box, so I would like some clarification.

Where does ResolvedFileToPublish get defined? Is this something we need to add to our unit test csproj file:

Ex:

<ItemGroup> <ResolvedFileToPublish Include="Microsoft.Extensions.DependencyInjection.dll" /> <ResolvedFileToPublish Include="Microsoft.Extensions.DependencyInjectionAbstractions.dll" /> </ItemGroup>

Thank you!

@MarcoRossignoli

[osiwshaya]

@Digiman , I too have this problem - were you able to resovle this?

[MarcoRossignoli]

The fix was done for dotnet publish are facing the issue after the publish?

If you run the publish using the /bl you should be able to see the coverlet files exclusion like here #1243 (comment)

[osiwshaya]

Hi @MarcoRossignoli ,

Yes, I am having this problem with publish.

I have explicitly added Microsoft.Extensions.DependencyInjection.Abstractions.dll and Microsoft.Extensions.DependencyInjection.dll as package references to the project, and after running the dotnet publish command, the output directory contains the 2.2.0 version instead of the expected 6.0.0 version.

Below is the sample command:

`C:\Code\MyCompany\application>dotnet.exe publish C:\Code\MyCompany\application\MyCompany.MyModule.MyProduct.Azure.Tests /bl --configuration Release --no-build -o c:\temp\pub
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

C:\Program Files\dotnet\sdk\6.0.300\MSBuild.dll -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\6.0.300\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\6.0.300\dotnet.dll -maxcpucount -property:PublishDir=c:\temp\pub -property:NoBuild=true -property:Configuration=Release -target:Publish -verbosity:m /bl C:\Code\MyCompany\application\MyCompany.MyModule.MyProduct.Azure.Tests\MyCompany.MyModule.MyProduct.Azure.Tests.csproj
MyCompany.MyModule.MyProduct.Azure.Tests -> c:\temp\pub`

[MarcoRossignoli]

@osiwshaya are you able to check the msbuild with https://msbuildlog.com/ like #1243 (comment) to check why the files are not excluded from the publish?