Microsoft (TFS) Build server - The type or namespace name '...' does not exist in the namespace '...' (are you missing an assembly reference?)

Question

I am working on setting up a buildserver for our team.

Background
We are using Microsoft Visual Studio 2010 Ultimate. Our product contains C# code(mainly), external DLL’s and C code. We are working with .Net 4.0 and have more than 70 projects.

We are working with 3 branches of our code:

• Production branche(what is currently released)
• Test branche(hot fixes, bug fixes, end user testing)
• Development branche(adding new fetures)

All the branches are under TF source control.

Goal
What we want is to have a build server to build and run all the unit tests for all the branches once a day, the build server should use the code in the source control. Our goal is to have some fast standard error detection. We would prefer as little to no maintaining of the build server.

We are not going to use the builds the buildserver produce, all we want is to use the build server to continuously to build and unit test our branches.

What is set up
There are currently set up two the build definition, one for the Test Branche and one for the Development Branche, both build definitions taking the code from the source control(that part works all good), but here is where the fun begins.

Problem
The Test Branche can build and run unit tests all fine.

The Development Branche cannot build due to an(or like 5 of) errors:

The type or namespace name 'XXX' does not exist in the namespace 'YYY' (are you missing an assembly reference?)

The error is for project X refereing to project Y. Both project X and Y is C# .Net 4.0 projects and we have fully control over both of them, both X and Y is compiled to DLL’s. Project Y contains a Interface the classes in project X are implementing.

The annoying detail is there is no difference in the Test Branche and Development Brance for either project X or Y. The two projects have been fully identical the last 3 month.

So the question is, why does it work in the Test Branche but not in the Development branche?

I have tested:
- The projects are correctly refered to each other. - All 3 Branches have no problem building on my own / any of my co-workers development machines(we have tested on 5 different machines). - I have tried to delete the whole X project and recreate it, didn’t work. - I have tried to delete the whole Y project and recreate it, didn’t work. - I have tried to change the namespace for project X project and its classes, didn’t work. - I have tried to change the namespace for project Y project and its classes, didn’t work. - (I have even restarted my development machine) - All the changes have always been checked into the source control where after the buildserver was set to build.

Extra information
I have been digging around in the logging files and found some interessting details, this is for the details of building project X in the Development Branche

Task "AssignProjectConfiguration"
  Project reference "..\..\A" has been assigned the "Debug|x86" configuration.
  Project reference "..\..\Y" has been assigned the "Debug|x86" configuration. (can see there is a project Y)
  Project reference "..\..\B" has been assigned the "Debug|x86" configuration.  

But then in the Task ”ResolveAssemblyReference”

Task "ResolveAssemblyReference"
  TargetFrameworkMoniker:
      .NETFramework,Version=v4.0
  TargetFrameworkMonikerDisplayName:
      .NET Framework 4
  TargetedRuntimeVersion:
      v4.0.30319
  Assemblies:
      System
      System.Xml.Linq
      System.Data.DataSetExtensions
      Microsoft.CSharp
      System.Data
      System.Xml
      System.Core
  AssemblyFiles:
      C:\Builds\1\A
      C:\Builds\1\B
(----- Missing project Y -----)
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll

Where in the Test Brance for the same task

Task "ResolveAssemblyReference"
  TargetFrameworkMoniker:
      .NETFramework,Version=v4.0
  TargetFrameworkMonikerDisplayName:
      .NET Framework 4
  TargetedRuntimeVersion:
      v4.0.30319
  Assemblies:
      System
      System.Data.Entity
      System.Xml.Linq
      System.Data.DataSetExtensions
      Microsoft.CSharp
      System.Data
      System.Xml
      System.Core
  AssemblyFiles:
      C:\Builds\1\A
      C:\Builds\1\B
      C:\Builds\1\Y (There it is)
     C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll

So it feels like it for some reason just ”forgets” the reference from project X to project Y.

Help

Answer 1

I had the same problem.

It took me few hours to find out that in this case the problem was not my fault :-)

http://support.microsoft.com/kb/2516078 :

This issue occurs due to a bug in the Path.GetFullPath in .NET Framework library. This is a known issue in Visual Studio 2010

Symptoms:

... when you try to build a solution with multiple projects where there exists dependency relationships among them, in specific conditions a build fails with the following error message.

Error Message: “C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (1200, 9): warning: The referenced project 'Relative path to the referenced project from the current directory’ does not exist.”

A build fails with the error message above when the following conditions are met.

1. You have a solution with multiple projects where there exists dependency relationships among them.
2. The sum of the following two path length is exactly added up to 259 characters (= MAX_PATH – 1)

1) The path of a referencing project’s directory. 2) The relative path to a referenced project from the current directory (= a referencing project’s directory).

NOTE: MAX_PATH is the maximum path length defined by Windows API and is set to be 260 characters.

Workaround:

To work around this issue, you can change path length and make sure that the sum of the following two path length is NOT added up to 259 characters.

1. The path of a referencing project’s directory.

2. The relative path to a referenced project from the current directory (= a referencing project’s directory).

Answer 2

I encountered the same error recently. The solution built locally in VS2010 just fine, but consistently failed on the build server. In the end, the MSBuild definition was set to the Release x86 configuration, but the complaining project referenced an assembly in bin\x86\Debug, instead of bin\x86\Release.

Verifying the release version of the assembly was referenced instead of the debug version (and correcting as needed) seemed to do the trick for me.