NuGet error in TeamCity: The process cannot access the file because it is being used by another process

Question

We're using TeamCity (9.0) as our CI server to build, test and deploy several applications. Recently we are seeing occassional (one in every 30/40 builds or so) NuGet (2.8.3) errors as follows:

[restore] The process cannot access the file 'C:\BuildAgent\work\e32cbd0940f38bf.....\packages\Newtonsoft.Json.5.0.6\Newtonsoft.Json.5.0.6.nupkg' because it is being used by another process.

where the actual package seems to differ from time to time.

We suspected it has something to do with the same package being referenced in multiple projects within the same solution, but I would expect NuGet to be able to handle this correctly by filtering out duplicates instead of attempting to retrieve the same package multiple times, thereby ending up with write-locks when restoring the packages to the work folder.

As a first step of each Build Configuration we have a 'NuGet Installer' step set to 'restore'. I've tried fiddling with its settings (different 'Update modes', '-NoCache', older NuGet version (2.8.0)), but to no avail.

Has anyone else experienced similar issues, and if so, has any suggestions on how to ensure this error does not occur.

Any help would be greatly appreciated!

Answer 1

I had the same issue with Jenkins and fixed that by adding "-DisableParallelProcessing" to the nuget restore command, the final command would look like:

nuget restore "%WORKSPACE%\Solutions\App\App.sln" -DisableParallelProcessing

Answer 2

Excluding NuGet package files from our anti-malware products resolved this issue for us.

I used the SysInternals Process Explorer utility on the build agents to search for file handles for any *.nupkg files while the builds were running. After several builds I observed the anti-malware products briefly locking these files during the NuGet restore operations. Adding an exclusion to the anti-malware scanning rules prevented these locks as the files were no longer being scanned.

In our environment we use two different anti-malware products on different build agent servers. We encountered this issue with both products.