We use CI for our Sharepoint projects. Some time ago we performed upgrade to TFS 2010 from 2008 version. After migration when all functionality of source control was working we encountered with problem that our build server failed to build solutions. One of the solutions contains ~ 40 projects. During investigation of build logs I found that it contains the following errors:
CSC : error CS0006: Metadata file MyProject.dll could not be found
Such errors occurred when msbuild tried to build projects which have dependencies on MyProject.dll, i.e. not MyProject itself. According to logs MyProject was not build at all at the moment when msbuild compiled dependent projects (projects which have reference on MyProject). So my hypothesis was that problem is caused somehow by wrong build order.
After searching some time I found that other people also encountered with such problems. In some forums people complained that this error may occur also on TFS 2008 (in our case it worked well until upgrade). It was also mentioned that problem is caused by wrong build order. At the same time build order in VS was correct and projects were built successfully in it. So seems like VS and msbuild use different ways to determine build order.
During investigation of build order problem in msbuild I found useful post where author explicitly specified project dependencies in VS solution (sln file) in text editor (in case of 2008 version). So for example if you have 2 projects in solution Project1 and Project2 where Project2 depends on Project1 (Project2 has reference on Project1) then you should specify it in sln file by the following way:
This is very creative work to specify all dependencies manually using projects guids if you have ~ 40 projects in solution :) Likely I was forced to do it only for several core projects (which almost all other projects have reference to) and for those projects which caused errors in build log. It was enough to help msbuild to untie the tangle of build dependencies. After that our build server started to work again.