9

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

Mr. JWolf
  • 1,375
  • 2
  • 14
  • 33
  • If you build with the MSBuild logging detail set to Detailed or Diagnostic it should spit out a lot more information during the ResolveAssemblyReference task, including every place it looked for and didn't find a reference. Does that have any warnings/errors? – Michael Edenfield Apr 16 '12 at 13:56
  • 1
    Just before the "ResolveAssemblyReference" task it throws this warning: `Task "Warning" c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1200,9): warning : The referenced project '..\Y' does not exist. [C:\Builds\1\X] Done executing task "Warning".` – Mr. JWolf Apr 16 '12 at 15:12
  • I can see earlier in the log-file there is: `Did not copy from file "C:\Builds\1\...\...\y" to file "C:\Builds\1\y" because the "SkipUnchangedFiles" parameter was set to "true" in the project and the files' sizes and timestamps match.` So it does look like it should be there. And further more, the Y dll is sent to the drop location, but X dll is not. So the Y dll is compiled. – Mr. JWolf Apr 16 '12 at 15:21
  • After you run the build, go on to the build machine and check to make sure that the project outputs are where you expect. (The TFS build doesn't clean the build output until the start of the next build so everything will be there.) Also, you can try running `msbuild` directly on the source code from the build machine, in case it's TFS that is messing things up. – Michael Edenfield Apr 19 '12 at 14:35

6 Answers6

6

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).

Kraken101
  • 164
  • 2
  • 6
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.

colbybhearn
  • 452
  • 9
  • 21
1

The problem on my end was entirely different unfortunately.

I was building two different versions of the same common code, one for .Net4 and another for Silverlight 5, with the same file name (.Framework.dll).

Since the build server outputs everything to the same folder by default, the Silverlight version of the assembly ended up overwriting the .Net4 one because msbuild decided to build it later. This caused a problem as soon as the next project in the solution was built, which was dependent on some classes that were available on the .Net4 version of the dll, but not on the Silverlight one.

I ended up splitting the projects in multiple solutions and setting the 'Solution Specific Build Outputs' option to true on the build definition 'Process' tab.

julealgon
  • 7,072
  • 3
  • 32
  • 77
1

I had a very similar issue. I found that in the Configuration Manager, under the Release Configuration, the platform was set to Any CPU and the Build checkbox was not checked.

Setting the platform to x86 (as all my other projects are set to this for legacy reasons) and making sure the project was set to Build under this configuration fixed my issue.

Adam Marshall
  • 126
  • 4
0

I've just had a similar issue and it ended up being the developer who last worked on the code decided to add references to some dlls in the obj\debug directory.

Mike Cheel
  • 12,626
  • 10
  • 72
  • 101
0

It is a bit old question but I've just come across similar issue and in my case it was the wrong referenced project Id (let's call it B) in the .cproj file of the project that was failing (project A). Originally, I copied the project A from another solution and included it in the solution I am working with now. The referenced project B was also present in both solutions so Visual Studio automatically resolved references even though in the A's .cproj referenced project B was still pointing to the B in the solution I copied it from:

<ProjectReference Include="..\B.csproj">
  <Project>{F3006530-D421-4A89-AA8B-376DBAA31E03}</Project> - wrong Id!
  <Name>ProjectB</Name>
</ProjectReference>

Weirdly, Visual Studio would ignore the incorrect Id and presumably use the path only so there were no build errors and correct dll would appear in project A's bin. MSBuild on my build server wouldn't be that liberal though. To fix it you can either edit .cproj file in a text editor or simply remove references and add them back making sure they're in your current solution.

Jerrington
  • 113
  • 4