Concurrent "dotnet tool restore" fails, DotnetToolSettings.xml is being used by another process

427 Views Asked by At

One of our projects runs dotnet tool restore as part of its postbuild step. On CI this build step is run multiple times in concurrent pipeline stages (not ideal but it's what we're working with...). E.g. the "Build" stage will build the project and do a dotnet tool restore, and the "Test" stage will also build the project and do a dotnet tool restore.

Sometimes, one of the stages fails during the restore:

PostBuild:
     System.AggregateException: One or more errors occurred. (Failed to retrieve tool configuration: The process cannot access the file 'C:\Users\AzDevOps\.nuget\packages\dotnet-typegen\3.0.0\tools\net6.0\any\DotnetToolSettings.xml' because it is being used by another process.)
       ---> Microsoft.DotNet.ToolPackage.ToolConfigurationException: Failed to retrieve tool configuration: The process cannot access the file 'C:\Users\AzDevOps\.nuget\packages\dotnet-typegen\3.0.0\tools\net6.0\any\DotnetToolSettings.xml' because it is being used by another process.

It always seems to be the same stage that fails, presumably due to how long the other stages take / when this last stage starts.

I see that there is a --disable-parallel flag however from what I can tell that will disable restoring multiple tools in parallel within a single dotnet tool restore, and won't help in this situation where multiple separate restores are being run.

I could move the dotnet tool restore out of the projects postbuild event and into its own pipeline step, and prevent the issue in the pipeline, but then I'll have the issue where the tool won't automatically restore on local dev workstations (since dotnet tool restore doesn't get run automatically via nuget restore / via visual studio).

I want the tool to be hooked up to the projects postbuild event so it runs on every build - what is the best way to ensure that tool is always there on CI / local dev env, ideally without manually installing things / rolling things out to workstations, and ideally managing tool versioning within the repository?

0

There are 0 best solutions below