6

I'm trying to improve build times using CruiseControl.NET and MSBUILD, and one of the commandline switches, maxcpucount can be used to allow the build occur in parallel. Our solution has 60+ projects so any improvement would be helpful. However, whenever I up the maxcpucount above one, we have frequent build failures due to:

"The process cannot access the file xxxx because it is being used by another process. msbuild"

It appears that the additional parallel build threads/processes are locking each other.

Mrchief
  • 75,126
  • 20
  • 142
  • 189
JNappi
  • 1,495
  • 1
  • 14
  • 24

4 Answers4

3

I think I found a solution. It appears that if I add the /nodeReuse:false switch I don't get the file locks. It seems like the nodeReuse functionality is keeping msbuild processes around and those are hanging on to file locks for subsequent builds.

http://msdn.microsoft.com/en-us/library/ms164311.aspx

JNappi
  • 1,495
  • 1
  • 14
  • 24
  • This actually didn't work. It seemed good for a few builds but eventually I endeded with broken builds due to dll's being locked. – JNappi Jul 28 '11 at 19:46
  • Are you sure its msbuild who's locking the file? Can you confirm via Process Explorer or similar utility? – Mrchief Sep 01 '11 at 04:19
2

Are you building from a solution file? If so, make sure that you are using direct project-to-project references and not using the Solution's project-dependency feature. If you happen to be using a bit of both, there can be issues. See this article.

Better yet, if at all possible, ditch the solution file and create your own MSBuild file to drive your build.

Erlend Graff
  • 1,098
  • 16
  • 27
Brian Kretzler
  • 9,748
  • 1
  • 31
  • 28
1

msbuild could block itself when multi-thread mode and in a large project and many dependencies. My solution is to force it use only 1 thread, which could avoid the error although it takes more time to build.

In powershell, override MSBUILD_PROCESSES environment to 1

$env:MSBUILD_PROCESSES=1

Or pass the /m:1 directly to msbuild:

msbuild yourproject.csproj /m:1
YoungForest
  • 111
  • 1
  • 7
0

Your assembly is probably being used by another assembly thats being built. Make sure each assembly gets built before it's needed by other assemblies

tam
  • 1,583
  • 2
  • 13
  • 25