Uninstrumenting doesn't work when the same assembly is instrumented in multiple locations about minicover HOT 9 CLOSED

Nice diagnosis. I guess it should track assemblies by path, not just assembly name.

I will create a PR to fix it. Thanks

from minicover.

@Quickstream , it should be fixed now.

Can you please try the new nuget package: MiniCover 2.0.0-ci-20180211032654 ?

from minicover.

Hi,

I gave the new version I try. At first, it seemed to be working, but after a few attempts I ended getting the following error:

Unhandled Exception: System.ArgumentException: An item with the same key has already been added. Key:
at System.ThrowHelper.ThrowAddingDuplicateWithKeyArgumentException(Object key)
at System.Collections.Generic.Dictionary2.TryInsert(TKey key, TValue value, InsertionBehavior behavior) at System.Linq.Enumerable.ToDictionary[TSource,TKey,TElement](IEnumerable1 source, Func2 keySelector, Func2 elementSelector, IEqualityComparer`1 comparer)
at MiniCover.Reports.BaseReport.Execute(InstrumentationResult result, Single threshold)
at Microsoft.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args)
at MiniCover.Program.Main(String[] args)
...: warning MSB3073: The command "dotnet minicover htmlreport --workdir ../ --threshold 80" exited with code 134.

If I look at the coverage.json file, I see 2 entries for the same assembly in the "Assemblies" array, each of which has one entry in the "Locations" array. I think the expected result would be one entry in the Assemblies array with 2 entries in the Locations array.

from minicover.

Running dotnet build immediately prior to instrumentation didn't resolve the issue, but running dotnet clean, then dotnet build prior to instrumentation did resolve the issue.

However, if I then ran dotnet build on just my IntegrationTests project and then tried instrumentation again, I was able to reproduce the issue.

from minicover.

It creates 2 entries with same assembly because the assembly files are binary different, so the instrumentation might be different. Maybe one is obsolete after you partially built the solution.

It happens that even rebuilding an assembly from same source code, it will generate a different binary because there are some compilation timestamps inside the assembly.

I can fix the report to nicely handle the duplicated assembly on coverage.json. But I'm still not sure if that's a good approach. Maybe I will need to do a more fundamental change.

from minicover.

@Quickstream, that issue with report should be fixed on build: MiniCover 2.0.0-ci-20180214071708

Edit:
The only time I copied the Nuget version before the build finishes it failed to push nuget package 😄
https://travis-ci.org/lucaslorentz/minicover/builds/341312354

Use this version instead: MiniCover 2.0.0-ci-20180214203020

from minicover.

@Quickstream can we close this issue?

from minicover.

Sorry I'm on vacation. I haven't had a chance to try the latest build yet.

from minicover.

Should be fixed by now. Please, reopen the issue if necessary.

from minicover.