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.

[SmartmanApps]

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

What are the steps to do this? (have never done it before)

[SmartmanApps]

I got hit by this when I updated VS2019 (I believe that was the reason anyway). Fortunately I hadn't updated nor uninstalled VS2017 and I was able to get it working there. No help to me for projects which are using C#8 (not supported by VS2017) but it's another workaround for some whilst we await a fix.

[kamsar]

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

What are the steps to do this? (have never done it before)

https://docs.microsoft.com/en-us/dotnet/core/tools/global-json#sdk

[Kieranties]

I can confirm that (at least for my scenario) enforcing the use of netcore sdk 3.1.100 (LTS) appears to have resolved the issue. Updating to 3.0 did not.
In my project building on Azure Devops I am using the vs2019 win image, however this does not have the LTS version installed. I worked around this using the dotnet-install script to ensure the LTS version is installed before running any dotnet command. More details here: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

Failing: https://dev.azure.com/Kieranties/SimpleVersion/_build/results?buildId=240&view=logs&j=800c766b-cf7f-545c-6b0a-ae5b31f2fdcf&t=39c35361-d0fa-5a5b-07df-90fe37b2b8e2
Sucess: https://dev.azure.com/Kieranties/SimpleVersion/_build/results?buildId=242&view=logs&j=2d2b3007-3c5c-5840-9bb0-2b1ea49925f3&t=ac0b0b0f-051f-52f7-8fb3-a7e384b0dde9

[bddckr]

In my project building on Azure Devops I am using the vs2019 win image, however this does not have the LTS version installed.

I'm using the windows-latest hosted agents and these steps:

    - pwsh: |
        $currentVersion = dotnet --version
        $expectedVersion = (Get-Content global.json | ConvertFrom-Json).sdk.version
        $isVersionInstalled = ($currentVersion -eq $expectedVersion).ToString().ToLower()
        Write-Host "##vso[task.setvariable variable=isDotNetVersionInstalled]$isVersionInstalled"
      displayName: Set isDotNetVersionInstalled Variable

    - task: UseDotNet@2
      displayName: Use .NET Core SDK from global.json
      condition: and(succeeded(), ne(variables['isDotNetVersionInstalled'], 'true'))
      inputs:
        packageType: sdk
        useGlobalJson: true
        includePreviewVersions: true

The first step actually results in isDotNetVersionInstalled getting set to true currently, so the hosted agents do come with 3.1.100 (as specified in my global.json).

---

Since updating to 3.1.100 I have not seen this error a single time anymore. I was previously hitting the issue approximately 40% of my pipeline runs.

[cryptomatt]

Still seeing this error with Visual Studio Build Tools 16.4.1, nuget 5.4.1 and dotnet core sdk 3.1.1

now the error is as high as 80% of the times. Will try with the Nuget.Client fix 3170.

[agrothe]

Had this issue with VS2019 today when upgrading a bunch of .NET Core libraries from version 3.1.1 to 3.1.2. Eventually figured out if you Clean the solution first it removes the error and works as expected. Not sure if VS or NuGet is locking the file, but hope this helps someone else who also lands here on a search.

VS: 16.4.5
NUGET: Version 5.4.0