Building solution with --runtime fails with error LIB003

Start by reproducing the failure with libman.json and the two dotnet restore/build commands in the microsoft/dotnet:2.2.103-sdk-nanoserver-1809 container, comparing builds with and without --runtime win-x64. Check whether concurrent restores from the test projects target the same files; done means the solution builds successfully with --runtime and no LIB003 errors.

Functional impact

Build fails in CI server

Minimal repro steps

I have a build pipeline that runs each step in the nano sdk container on Windows 2019 (microsoft/dotnet:2.2.103-sdk-nanoserver-1809). The source code folder is mapped into the container as a volume.

My solution contains a web project, a couple of support projects and a couple of test projects that depend on the web project

1. dotnet restore my.sln --configuration release --runtime win-x64
2. dotnet build my.sln --configuration release --runtime win-x64 --no-restore

Step 2 fails with multiple instances of error LIB003, each for a different file. The files in question are present

libman.json : error LIB003: css/bootstrap-grid.min.css.map could not be written to disk. Make sure the file name is correct

Expected result

The build would work

Further technical details

• Running a LibMan CLI step before the build to restore the packages doesn't solve the issue
• Removing the --runtime win-x64 option works.
• Doing the build on the web project works.

My guess is that there's a race condition between concurrent downloads of the packages caused by builds of the test projects. When --runtime is specified the output shows 2 instances of

  Restoring library twitter-bootstrap@4.3.1...
  Restoring library jquery@3.3.1...
  Restoring library jquery-validate@1.19.0...
  Restoring library jquery-validation-unobtrusive@3.2.11...
  Restoring library popper.js@1.14.7...

  5 libraries restored in 0.18 seconds

whereas without it only 1 restore is done.