visual-studio-2010 - Microsoft (TFS) 构建服务器 - namespace '...' 中不存在类型或 namespace 名称 '...'(您是否缺少程序集引用？)

Question

我正在为我们的团队建立一个构建服务器。

背景
我们正在使用 Microsoft Visual Studio 2010 Ultimate。我们的产品包含 C# 代码(主要)、外部 DLL 和 C 代码。我们正在使用 .Net 4.0 并拥有 70 多个项目。

我们正在使用我们代码的 3 个分支:

生产分支(目前发布的内容)

测试分支(热修复、错误修复、最终用户测试)

开发分支(新增功能)

所有分支都在 TF 源代码控制之下。

目标
我们想要的是有一个构建服务器来构建和运行所有分支的所有单元测试，每天一次，构建服务器应该使用源代码控制中的代码。我们的目标是进行一些快速的标准错误检测。我们宁愿少维护构建服务器。

我们不会使用 buildserver 生成的构建，我们只想使用构建服务器来持续构建和单元测试我们的分支。

设置了什么
当前设置了两个构建定义，一个用于测试分支，一个用于开发分支，两个构建定义都从源代码控制中获取代码(这部分工作正常)，但这里是乐趣的开始。

问题
测试分支可以很好地构建和运行单元测试。

由于(或类似 5 个)错误，开发分支无法构建:

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

错误是项目 X 引用项目 Y。项目 X 和 Y 都是 C# .Net 4.0 项目，我们可以完全控制它们，X 和 Y 都编译为 DLL。项目 Y 包含项目 X 中的类正在实现的接口(interface)。

烦人的细节是项目 X 或 Y 的测试分支和开发分支没有区别。这两个项目在过去 3 个月中完全相同。

所以问题是，为什么它在测试分支中起作用，而在开发分支中不起作用？

我测试过:
- 项目相互正确引用。
- 在我自己/我的任何同事开发机器上构建所有 3 个分支都没有问题(我们已经在 5 台不同的机器上进行了测试)。
- 我试图删除整个 X 项目并重新创建它，但没有成功。
- 我试图删除整个 Y 项目并重新创建它，但没有成功。
- 我试图更改项目 X 项目及其类的命名空间，但没有成功。
- 我试图更改项目 Y 项目及其类的命名空间，但没有成功。
- (我什至重新启动了我的开发机器)
- 在构建服务器设置为构建之后，所有更改都始终检查到源代码管理中。

额外信息
我一直在挖掘日志文件，发现了一些有趣的细节，这是在开发分支中构建项目 X 的​​细节

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.  

但随后在任务“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

在同一任务的测试分支中的哪个位置

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

所以感觉就像它出于某种原因只是“忘记”了从项目 X 到项目 Y 的引用。

帮助

Answer 1

我有同样的问题。

我花了几个小时才发现在这种情况下问题不是我的错:-)

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

症状:

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

解决方法:

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