MSBuild maxcpucount > 1 Causes build errors

Question

I'm trying to build about 600 projects some are .net 2.0, some are 3.5. I'm using Windows 2003 Enterprise Edition 32 bit with all the latest windows updates.

Builds fine when maxcpucount is 1. If I bump it up to try and improve performance it get reference errors. When I look at the project references from where the error occurred it appears they should have been built in order.

Below I've provided an example of the errors that are causing the build to be broken. Don't get hung up on the project names or the relative paths because I've changed this so I don't get in trouble with my employer.

It's like the relative project references can't be properly resolved when more then one core is building the solution.

"C:\SVN\MyLibrary\MyLibrary.csproj" (default target) (15) ->
   "C:\SVN\FileProcessor\FileProcessor.csproj" (default target) (17) ->
   (ResolveProjectReferences target) ->
     C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning : The referenced project '..\..\Manager\Manager.csproj' does not exist.


   "C:\SVN\MyLibrary\MyLibrary.csproj" (default target) (15) ->
   "C:\SVN\FileProcessor\FileProcessor.csproj" (default target) (17) ->
   (CoreCompile target) ->
     FileProcessor.cs(18,39): error CS0234: The type or namespace name 'Manager' does not exist in the namespace 'TheNamespace' (are you missing an assembly reference?)

I'm not using msbuild on a solution file. I'm using wildcards to select all csproj files then feeding them to msbuild. For development we have multiple solutions we use for different components of the system. 95% are project reference, the only binary references are for core utility libs

Hallam

Answer 1

In order for MSBuild to run with multiple cores/cpus, it needs to be able to determine beforehand what all of the dependencies are. Generally this means you either need to have all of your projects in a single huge solution and set up all of your references to be project references or set up multiple solutions and set them to build in the correct order.

It sounds like you're running the single solution version right now, so you'll want to make sure all of your references to your other projects are set up correctly as project references, not filepath references.

I haven't found a good way to check this with the GUI, so you'll probably have to unload and edit one of the project files that isn't building in multicpu to take a look at the xml.

A project reference should look like:

<ProjectReference Include="..\..\Manager\Manager.csproj">
      <Project>{C0F60D74-3EF9-4B49-9563-66E70D0DDF43}</Project>
      <Name>Manager</Name>
</ProjectReference>

and a filepath reference would look like:

<Reference Include="Manager.dll, Version=2.0.0.0, Culture=neutral, PublicKeyToken=e79aa50eb4f67b0c, processorArchitecture=MSIL">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>....\Manager\Manager.dll</HintPath>
</Reference>

It looks like you have at least some of your references set up correctly, since the error message you have has at least one call out to another project, so you shouldn't need to update everything, just check on the couple that are giving you problems.

Benign

I'm not using msbuild on a solution file. I'm using wildcards to select all csproj files then feeding them to msbuild. For development we have multiple solutions we use for different components of the system. 95% are project reference, the only binary references are for core utility libs. – Hallam

Answer 2

I could be quite late and you might have solved this problem. But I was stuck with the same error and found that it was due to the path length of one of my projects being too large. Please see here

Maryrose