coverlet: Could not write lines to file CoverletSourceRootsMapping - in use by another process
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?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 8
- Comments: 33
Commits related to this issue
- Update dependency coverlet.collector to v6 (#754) [](https://renovatebot.com) This PR contains the following updates: | Package | Type... — committed to cythral/brighid-commands by renovate[bot] a year ago
- chore(deps): update dependency coverlet.collector to v6 (#314) [](https://renovatebot.com) This PR contains the following updates: | P... — committed to Testably/Testably.Abstractions by renovate[bot] a year ago
- Update dependency coverlet.collector to v6 (#436) [](https://renovatebot.com) This PR contains the following updates: | Package | Type... — committed to ThorstenSauter/NoPlan by renovate[bot] a year ago
- chore(deps): update dependency coverlet.collector to v6 (#50) [](https://renovatebot.com) This PR contains the following updates: ... — committed to Testably/Testably.Architecture.Rules by renovate[bot] a year ago
- ⬆️ Update Coverage Packages to v6 (major) (#79) [](https://renovatebot.com) This PR contains the following updates: | Package | T... — committed to bruxisma/atmosphere by renovate[bot] a year ago
- chore(deps): update dependency coverlet.msbuild to v6 (#31) [](https://renovatebot.com) This PR contains the following updates: |... — committed to apollographql/federation-hotchocolate by renovate[bot] 8 months ago
This fix is not yet merged…I’m having some hassle on tests and I’m a bit busy, I’ll try to work on it asap.
Not yet, I’m having issue with this fix in CI…I need to investigate a bit more.
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.
Hi all,
I’ve published a test package here https://f.feedz.io/marcorossignoli/coverletunofficial/nuget/index.json the versions are
coverlet.collector 3.1.3-preview.7.gb1603b798b coverlet.msbuild 3.1.3-preview.7.gb1603b798b
I need help, can someone give it a try and let me know if it’s working?
Yes, we observe the same - 85% chance of error, prior to net6 we haven’t seen this error.
I’ve started to work on this one the idea is to create the file mapping using some sort of hash for the “current” test container to avoid collision in case of solutions with more containers in the same output folder. Something like
Let’s see it it can work…there’re some place to change:
cc: @daveMueller
We have the same issue, basically the scenario is:
Since this is a “build timing” bug related to writing to the same file, it is not 100% reproducable.
However, I think a good fix would probably be to append or prefix the
MSBuildProjectNameto theCoverletSourceRootsMappingfile, e.g._sourceRootMappingFilePath: “$([MSBuild]::EnsureTrailingSlash(‘$(OutputPath)’))CoverletSourceRootsMapping -$(MSBuildProjectName)”
This will ensure that the CoverletSourceRootsMapping file is unique per MSBuildProject (i.e. per Assembly)
Same problem here. Build with single process with a solution >50 projects is not an option.
Yes, a
CoverletSourceRootsMapping_dlltestname.Testsfile was created for every test project in the solution.thanks @bretthysuik can you confirm that in you output folder you see a list of
CoverletSourceRootsMapping_dlltestname?Can someone else give a try to coverlet.msbuild
3.1.3-preview.7.gb1603b798b?I don’t think that is enough only update with the guid some code needs review
https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.core/Helpers/SourceRootTranslator.cs https://github.com/coverlet-coverage/coverlet/blob/master/src/coverlet.core/Reporters/CoberturaReporter.cs#L71
Tests are here https://github.com/coverlet-coverage/coverlet/blob/master/test/coverlet.integration.tests/DeterministicBuild.cs
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.
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.
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, andMSTest.TestFrameworkto 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!