Running coverlet on a sln results in fatal exception

This is a new regression in dotnet core 3 - we did not encounter this issue using coverlet collectors in 2.2.401. I have something like 40 test csproj files in mycode.sln.

When I run dotnet test mycode.sln --collect:"XPlat Code Coverage"

I inevitably at some point in the run will get

[22:13:31][Step 6/10] Data collector 'XPlat code coverage' message: Coverlet.Collector.Utilities.CoverletDataCollectorException: CoverletCoverageDataCollector: Failed to get coverage result
[22:13:31][Step 6/10]  ---> System.IO.IOException: The process cannot access the file '/opt/teamcity/temp/buildTmp/MP_2ccfd88a-3ed0-4316-9bdc-3213e6db0213' because it is being used by another process.
[22:13:31][Step 6/10]    at System.IO.FileStream.Init(FileMode mode, FileShare share, String originalPath)
[22:13:31][Step 6/10]    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
[22:13:31][Step 6/10]    at Coverlet.Core.Coverage.CalculateCoverage()
[22:13:31][Step 6/10]    at Coverlet.Core.Coverage.GetCoverageResult()
[22:13:31][Step 6/10]    at Coverlet.Collector.DataCollection.CoverageWrapper.GetCoverageResult(Coverage coverage)
[22:13:31][Step 6/10]    at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult()
[22:13:31][Step 6/10]    --- End of inner exception stack trace ---
[22:13:31][Step 6/10]    at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult()
[22:13:31][Step 6/10]    at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageReport()
[22:13:31][Step 6/10]    at Coverlet.Collector.DataCollection.CoverletCoverageCollector.OnSessionEnd(Object sender, SessionEndEventArgs e).

Pretty clearly it’s contending over the same tmp file for coverage info. FWIW, this is much more likely to happen when I am running directly from the command line vs using a .runsettings file - though I believe it has happened in either case.

[reverseark]

Just to report we hit exactly the same issue and search engine leads me here. Version of collector package is 1.2.0. It is not an easy repro though, probably once every 20-30 runs.

I read through this thread. The MaxCpuCount not respected by dotnet test issue has been well discussed here.

I also saw the description about what is happening behind the scene with. It seems this kind of issue will happen by nature, unless this design is changed “one tmp file for every dll”.

Thanks!

[MarcoRossignoli]

Close for stale conversation.

Feel free to re-open if needed.