I use NuGet to share the output of CI builds with other software components. I've wired up a system that uses the command line .exe to pack, push, and install dependent modules, and I frequently run into this error running the install command in builds that share a common component:
GET <URLToMyFeed>/Packages()?$filter=tolower(Id) eq '<MyPackage>'&$orderby=Id
System.IO.IOException: The process cannot access the file 'C:\Users\<buildUser>\AppData\Local\NuGet\Cache\<MyPackage>' because it is being used by another process.
followed by a stack trace.
This error is caused by concurrent builds on the same machine, both of which require <MyPackage> to build, executing the install step, unpacking the software to their workspace, but then simultaneously sticking a copy of the package in the cache directory, which is a common location. Additionally, the packages are kind of large, so it increases the odds of collision.
As far as I can tell, I cannot control the location of the cache directory, either as an option via the install command, or in the NuGet .config file, to help eliminate this contention point. The only way I think I can solve this class of problems, is to ensure the builds do not run concurrently, or separate them to different systems. I have a number of different modules, though, and I'd like to better utilize my system resources.
It would be great if there was the ability to provide some option(s) on the command line during install to specify a cache directory which would allow each build to have it's own cache location, and/or the ability to not post a copy of the package to the cache.
Thanks
Comments: You can control this via an environment variable in the latest version. If you set an environment variable called "NuGetCachePath" to a full path that exists, and do this per environment prior to running the nuget command, you should be able to get each outputting to a different cache directory. See code here: https://nuget.codeplex.com/SourceControl/latest#src/Core/Repositories/MachineCache.cs
GET <URLToMyFeed>/Packages()?$filter=tolower(Id) eq '<MyPackage>'&$orderby=Id
System.IO.IOException: The process cannot access the file 'C:\Users\<buildUser>\AppData\Local\NuGet\Cache\<MyPackage>' because it is being used by another process.
followed by a stack trace.
This error is caused by concurrent builds on the same machine, both of which require <MyPackage> to build, executing the install step, unpacking the software to their workspace, but then simultaneously sticking a copy of the package in the cache directory, which is a common location. Additionally, the packages are kind of large, so it increases the odds of collision.
As far as I can tell, I cannot control the location of the cache directory, either as an option via the install command, or in the NuGet .config file, to help eliminate this contention point. The only way I think I can solve this class of problems, is to ensure the builds do not run concurrently, or separate them to different systems. I have a number of different modules, though, and I'd like to better utilize my system resources.
It would be great if there was the ability to provide some option(s) on the command line during install to specify a cache directory which would allow each build to have it's own cache location, and/or the ability to not post a copy of the package to the cache.
Thanks
Comments: You can control this via an environment variable in the latest version. If you set an environment variable called "NuGetCachePath" to a full path that exists, and do this per environment prior to running the nuget command, you should be able to get each outputting to a different cache directory. See code here: https://nuget.codeplex.com/SourceControl/latest#src/Core/Repositories/MachineCache.cs