Could not write lines to file CoverletSourceRootsMapping - in use by another process

[ta264]

Our build process with coverlet > 3.0 tends to fail with an error like this:

C:\Users\VssAdministrator\.nuget\packages\coverlet.collector\3.0.4-preview.25\build\netstandard1.0\coverlet.collector.targets(48,5): error MSB3491: Could not write lines to file "..\..\_tests\net5.0\linux-musl-arm64\CoverletSourceRootsMapping". The process cannot access the file 'D:\a\1\s\_tests\net5.0\linux-musl-arm64\CoverletSourceRootsMapping' because it is being used by another process. [D:\a\1\s\src\NzbDrone.Host.Test\Radarr.Host.Test.csproj]
  Radarr.Windows.Test -> D:\a\1\s\_tests\net5.0\linux-musl-x64\publish\

I suspect this is because we have a centralized output directory (not one per project).

  <PropertyGroup>
    <!-- Output to _output and _tests respectively -->
    <OutputPath Condition="'$(RadarrProject)'=='true'">$(RadarrRootDir)_output\</OutputPath>
    <OutputPath Condition="'$(RadarrOutputType)'=='Test'">$(RadarrRootDir)_tests\</OutputPath>
  </PropertyGroup>

Can this be worked around at all?

[MarcoRossignoli]

Unfortunately at the moment CoverletSourceRootsMapping uses $OutputPath https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.collector/build/netstandard1.0/coverlet.collector.targets#L46

[LevYas]

I have the same issue. Looks like as a workaround we can build tests into a subdirectory of that centralized directory.

[MrOwen]

@LevYas can you expand on your workaround? I'm using --output flag with the dotnet cli so I don't specify the output at the project level but the solution I'm building contains multiple projects. Does that mean a different build output needs to be specified in each project file in the solution and I can't use the cli --output flag? Seems like an arduous workaround that's error prone if you expect to put this all into an automated build.

If this is a race condition (I expect it is as I run into about 75% of the time), can it be solved with some retry logic? I grabbed the following from the same dotnet publish step and there is some retry logic going on so I'm wondering if the same can be done for the CoverletSourceRootsMapping file:

Copying file from "C:\Users\ContainerAdministrator\.nuget\packages\coverlet.collector\3.0.3\build\netstandard1.0\System.Linq.Expressions.dll" to "C:\__w\165\b\SampleAPI\System.Linq.Expressions.dll".
9:6>C:\Users\ContainerAdministrator\.nuget\packages\coverlet.collector\3.0.3\build\netstandard1.0\coverlet.collector.targets(16,5): warning MSB3026: Could not copy "C:\Users\ContainerAdministrator\.nuget\packages\coverlet.collector\3.0.3\build\netstandard1.0\System.Linq.Expressions.dll" to "C:\__w\165\b\SampleAPI\System.Linq.Expressions.dll". Beginning retry 1 in 1000ms. The process cannot access the file 'C:\__w\165\b\SampleAPI\System.Linq.Expressions.dll' because it is being used by another process.  [C:\__w\165\s\project\API\Sample.Tests\Sample.Tests.csproj]

[LevYas]

@MrOwen Sure. I have output setup per project for all my projects, and I use CI/CD. Here's how it looks like for test project:

<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
<AppendRuntimeIdentifierToOutputPath>false</AppendRuntimeIdentifierToOutputPath
<OutputPath>..\..\..\Bin\$(Configuration)\Tests\Unit</OutputPath>

[MrOwen]

Ah, that's what I was afraid of. I'm working on a project with 60 test projects... I actually ended up upgrading Microsoft.NET.Test.Sdk, MSTest.TestAdapter, and MSTest.TestFramework to their latest versions since we were way behind and all issues seem to have gone away. Tried looking in the changelogs for each of these to see if some sort of race-condition was fixed but didn't spot any specifically. Either way, for future peeps stumbling on this problem, there's a few fixes in this thread now. Thanks again @LevYas!

[echalone]

We had the same problem now. Our "workaround" for now was to only build with a single process instead of multiple. Not ideal though as the build will take longer once the solution grows.

[zplan]

Same problem here.
Build with single process with a solution >50 projects is not an option.

[MarcoRossignoli]

For now a possible solutions could be update coverlet to write the mapping in a folder like $(OutputPath)\CoverletSourceMappings\CoverletSourceRootsMapping_{Guid}` and merge/use when needed.

[cboulva99]

Hello!

Any development on this subject? It seems since we migrated to .net6, the bug occurs almost always. We did not have the problem before that.

[maxpavlov]

Hello!

Any development on this subject? It seems since we migrated to .net6, the bug occurs almost always. We did not have the problem before that.

Yes, we observe the same - 85% chance of error, prior to net6 we haven't seen this error.

[DamianSuess]

Any word on the progress, or if the community should aim to assist on this fix?
For efficiency purposes, we keep our tests in an Output\Tests\ folder in our projects for accessibility, reduction of multiple DLLs, and easy-to-clean purposes.

However, we continuously get the error, "The process cannot access the file '...\CoverletSourceRootsMapping' because it is being used by another process. This is problematic for our build machines.

Thank you.

[MarcoRossignoli]

It's on high priority, but didn't have time to work on it yet, bit busy times.

Can someone provide a repro to speedups a bit the analysis?

Coverlet is open source if someone wants to take this one I'm glad to review and help.
In case let me know that I'll assign the issue to avoid to accidentally waste time.