Coverlet: ` Failed to resolve assembly` when running dotnet test with coverage

[PrzemekGawron]

When I run command
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover
all test are passing and code coverage is correctly generated which is good. However returned exit code from command is 1 due to this error:

coverlet.msbuild\1.0.2\build\netstandard2.0\coverlet.msbuild.targets(13,5): error : Failed to resolve assembly: 'Common, Version=1.1.0.0, Culture=neutral, PublicKeyToken=null' [C:\Source\Repos\MyApp\src\Test\Test.csproj]

Where Common is one of the referenced projects.
When I just run dotnet test everything is working and exit code is 0.

[tonerdo]

I believe this is the same as #21 which has been fixed in #23. A new NuGet package will go out next Monday with this fix

[tonerdo]

New NuGet released https://www.nuget.org/packages/coverlet.msbuild/1.1.0. Feel free to reopen if you still run into the issue

[PrzemekGawron]

Works like a charm. Thank you!

[jp7677]

Just for reference, I had the same issue with some 3rd party packages, even with version 1.1.1.
Including
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
in the project file of my test project fixed it for me.

[peterdeme]

Confirmed, I've got Failed to resolve assembly: 'Microsoft.Extensions.Logging.Abstractions error and <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> solved my issue, too.

[jp7677]

PS: An even better way than modifying your *.csprof file is to run dotnet test like
dotnet test /p:CollectCoverage=true /p:CopyLocalLockFileAssemblies=true

[Thomas-Coville]

Thanks !

This also solved an issue for me when running tests on libraries relying on StackExchange.Redis.StrongName
with errors like coverlet.msbuild.targets(7,5): error : Failed to resolve assembly: 'StackExchange.Redis.StrongName, Version=1.2.6.0

[avivka]

Confirmed, I've got Failed to resolve assembly: 'Microsoft.Extensions.Logging.Abstractions error and running dotnet test like
dotnet test /p:CollectCoverage=true /p:CopyLocalLockFileAssemblies=true solved my issue, too.

[Structed]

Perhaps this can be added to the README.md, @tonerdo?

[davenewza]

Had this happening with 2.3.2. /p:CopyLocalLockFileAssemblies=true fixed it.

[keithwillcode]

Is using /p:CopyLocalLockFileAssemblies=true or <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies> the prescribed way to fix this error? Any plans/thoughts on a fix that wouldn't require using this parameter?