TFS + NuGet + /m:x = race condition

Feb 7, 2012 at 10:59 AM

Hi

First up, great job with nuget and CI :)

I've got a solution, with several (less than 10) projects and some of them are using the same NuGet Packages.

I've got my TFS to fetch the packages and that is all well, WHEN running a single thread on the TFS server (/m:1 standard switch to msbuild) But when i added more threads to speed the build up I'm getting "The process cannot access the file 'xxx' because it is being used by another process' in the install phase.
This sounds to me like two projects are trying to install the same package concurrently.

To make matters worse, I cannot reproduce the error on my dev box :(

I'm not quite sure if it is NuGet or TFS that is acting up, I'm hoping some of the bright minds in here can help me out :)

in the mean time I'm sticking with single threaded build...

 

regards

Dennis

Developer
Feb 7, 2012 at 7:00 PM

We ran into the exact issue when setting up package restore at one of our work projects. We're tinkering around with a couple of ideas on how to work with this, (placeholder files \ yanking package restore into a sequential build task etc) but nothing concrete as of yet.

Feb 16, 2012 at 1:01 PM

Yeah, or check the packages into TFS also seems to work, but i don't want that :)

Feb 17, 2012 at 11:53 AM

We wrote a console extension that takes the aggregate set of packages over the solution (no duplicates), and only gets the minimum unique set.  We don't run this on each project though, rather as an initial task, and we don't use package restore.  Some solutions it means approx. 75% less package requests, and subsequently a lot less time to retrieve them.  We do have a lot of packages per project though (sometimes upwards of ten) so this approach may not suit you.  Also solves the locking/multi-threaded problem.  We not only didn't find a nice solution to the multi-project file locking, in our case it seemed a little wasteful to restore per project anyway.  

We did look at refining this and making it an automatic build event.  Unfortunately MSBuild/VS2010 is not actually consistent during solution builds, we wanted to hook into the pre-Solution build events so that this would always get run, but once per solution run (as per here: http://sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx).  This solution only works when running from MSBuild, VS2010 ignores this completely.  If you are using MSBuild for the CI server, this may work, but it is pretty woeful that the same mechanism fails for a dev using VS2010.

Sorry can't help more.