Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When publishing test project "CopyCoverletDataCollectorFiles" overwrites project assemblies #1131

Closed
danielp37 opened this issue Mar 23, 2021 · 11 comments · Fixed by #1243
Closed
Labels
bug Something isn't working waiting for customer Waiting for customer action

Comments

@danielp37
Copy link

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.

@daveMueller daveMueller added the untriaged To be investigated label Mar 23, 2021
@MarcoRossignoli MarcoRossignoli added waiting for customer Waiting for customer action and removed untriaged To be investigated labels Apr 3, 2021
@MarcoRossignoli
Copy link
Collaborator

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
Copy link

mcm2020 commented Apr 17, 2021

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
Copy link

ta264 commented Apr 27, 2021

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
Copy link

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

@MarcoRossignoli
Copy link
Collaborator

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
Copy link

Digiman commented Apr 8, 2022

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
Copy link

osiwshaya commented Jun 9, 2022

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
Copy link

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

@MarcoRossignoli
Copy link
Collaborator

MarcoRossignoli commented Jun 10, 2022

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
Copy link

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
Copy link
Collaborator

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working waiting for customer Waiting for customer action
Projects
None yet
8 participants