restore fails when nuget.dgspec.json is "used by another process"

[AArnott]

I'm trying to renovate my PInvoke repo to use the latest .NET tooling, and in the process I've seen a high failure rate during package restore. For example in this build:

D:\a\1\s\src\BCrypt\BCrypt.csproj : error : One or more errors occurred. (The process cannot access the file 'C:\Users\VssAdministrator\AppData\Local\Temp\d7b7ea43-5b9f-4c98-9945-129825a55c6f.nuget.dgspec.json' because it is being used by another process.)

I've seen this error 2-3 times out of just half a dozen builds in Azure Pipelines.

restore command: dotnet restore
dotnet SDK: v2.2.401
nuget cred provider: v0.1.19 (from https://api.github.com/repos/Microsoft/artifacts-credprovider/releases/latest)

This particular repo (https://github.com/aarnott/pinvoke) has several dozen projects in a very flat P2P hierarchy, so a great many projects may be restoring in parallel, perhaps leading to this file access conflict.

[amis92]

I've been hit by this as well on cloud builds intermittently. I've found another issue about that as well: https://github.com/dotnet/corefx/issues/39153

I've been using MsbuildSdks in global.json as well.

[mjcheetham]

I am also seeing this problem. Using Azure Pipelines builds and MSBuild SDKs specified in a global.json file.

[Kieranties]

cross referencing my issue reported in corefx

We've been consistently hitting this issue when using additional SDKs specified in the global.json.
E.g. we use https://github.com/Microsoft/MSBuildSdks/tree/master/src/CentralPackageVersions in many projects and will often get:

1>Project "C:\BA\bed11ac6b8240753\xxx.AspNet.sln" on node 1 (Clean target(s)).
[10:24:17] 1>ValidateSolutionConfiguration:
[10:24:17] Building solution configuration "Debug|Any CPU".
[10:24:18] Restoring packages for C:\BuildAgent\temp\buildTmp\db0fd7f7-95fe-4b13-827b-6b3ce61569c6...
[10:24:18] 0>C:\BA\bed11ac6b8240753\test\xxx.Tests\xxx.Tests.csproj : error : One or more errors occurred. (The process cannot access the file 'C:\BuildAgent\temp\buildTmp\db0fd7f7-95fe-4b13-827b-6b3ce61569c6.nuget.dgspec.json' because it is being used by another process.)
[10:24:18] 1>Project "C:\BA\bed11ac6b8240753\xxx.AspNet.sln" (1) is building "C:\BA\bed11ac6b8240753\test\xxx.Tests\xxx.Tests.csproj" (2) on node 1 (Clean target(s)).
[10:24:18] 2>C:\BA\bed11ac6b8240753\test\xxx.Tests\xxx.Tests.csproj : error MSB4236: The SDK 'Microsoft.Build.CentralPackageVersions' specified could not be found.

Pinning the sdk to an older version (e.g. 2.1.503) resolves the issue, but this is not sustainable.

[bddckr]

We're hitting the exact same issues as @Kieranties mentioned: Using an additional SDK via the global.json and our first dotnet command fails every now and then.

We're also using Microsoft.Build.CentralPackageVersions. The first command we run is dotnet restore.

[donnie-msft]

Discussed with @jeffkl who says

I think it’s a product of no-op which shouldn't be used by the SDK resolver but since its calling common code it is.  It also could be manifesting because of a bug in MSBuild that I fixed in 16.4: dotnet/msbuild#4797

[amis92]

because of a bug in MSBuild that I fixed in 16.4

I don't think it's that because with SDK v3.1.100 (which uses msbuild 16.4 AFAIK) I've hit it as well:

Azure Pipelines build log

The process cannot access the file 'C:\Users\VssAdministrator\AppData\Local\Temp\3bf9a082-ede3-4cfa-aeb7-fecf1c695933.nuget.dgspec.json' because it is being used by another process.

In this case the global.json uses "MSBuild.Sdk.Extras" and "Microsoft.Build.NoTargets", so I don't think the specific MsbuildSdk referenced has any impact - just that there is some.

[asci13]

Is there any update on this? we're hit by this seemingly random a few times a day (across multiple projects) and a fix or an update on a timeline would be much appreciated.

[Kieranties]

I've ran into the same issue on another project running under Azure devops: https://dev.azure.com/Kieranties/SimpleVersion/_build/results?buildId=235&view=logs&j=caf81668-d14b-59f1-853a-f317fa077bd4&t=8c2e7626-5bb8-5934-d8c4-784548dbdb4d&l=28

I've now had several runs fail sequentially: https://dev.azure.com/Kieranties/SimpleVersion/_build?definitionId=1&_a=summary

[jeffkl]

You should hit this issue a lot less with MSBuild 16.4/.NET Core 3.1. I'm working on a fix in NuGet as well which should resolve it completely.