我有一个构建良好的项目如果我手动构建它但它在 CC.NET 中失败。
CC.NET 上出现的错误基本上与导入失败有关，因为找不到文件；其中一个项目（C++ dll）尝试导入由另一个项目构建的 dll。Dll 应该在正确的位置，因为项目之间存在依赖关系 - 确实，当我手动构建时一切正常（请注意，当我说手动时，我从源代码存储库中获取所有内容，然后从 VS2005 调用 Rebuild 来模拟 CC.NET自动化）。
当通过 CC.NET 自动构建时，似乎忽略了依赖项。
我正在 Release MinDependency 模式下构建。
任何帮助将不胜感激！
您可以更改 CC 以使用 msbuild 而不是 devenv 吗？这对我来说似乎是最佳解决方案，因为这意味着在两种情况下构建都是相同的。
经过长时间的调查 - 我在当前阶段对此的理解是，问题与我使用 devenv 通过 CruiseControl.NET 构建但当我手动构建时 VisualStudio 使用 msbuild 的事实有关。
基本上这会导致依赖项被忽略（因为我没有使用 devenv 复制一些 msbuild 命令 arg）。
我认为在 C++ 项目之间设置依赖关系这一事实在某种程度上也很重要，因为我已经能够在其他场合使用 CC.NET 正确构建 .NET 项目和 C++ 项目之间的依赖关系。
为了弄清楚究竟是什么产生了这种不同的行为，我必须遵循这条线索。
我想听听其他人对此的看法。
尝试从命令行构建它，看看会发生什么。
我的猜测是，配置服务的用户与实际运行它时具有不同的权限和/或环境变量。如果您在同一个物理盒子上，并且它与 Visual Studio 编译得很好，并且您还在 CruiseControl（而不是 MSBuild）中使用 Visual Studio，那么几乎可以肯定它是用户。但是，如果您在 CruiseControl 中使用 MSBuild，则 MSBuild (2.0) 编译 C++ sln 和 Visual Studio 编译它时会有很大的不同。如果您必须在 C++ 解决方案上使用 MSBuild，请尝试 v3.5，它对 C++ 解决方案有更多支持。
我想知道 CC.Net 是否正在使用不同的环境变量进行构建，从而没有将必要的库目录正确添加到路径中。
CC.Net 构建日志中是否有任何特定的错误消息说明特定 DLL 导入失败的原因？找不到文件？权限？查看详细的 CC.Net 构建日志以了解故障，并查看它与普通命令行构建的不同之处。
如果我在 IDE 中打开并编译我的解决方案，我会遇到这样的情况，但如果我从命令行（msbuild 或 devenv）运行则会失败。在每种情况下，问题都是由于参考错误 - 可能来自本地盒子和构建服务器之间不匹配的路径。您会看到它在 IDE 中正确编译，因为 VisualStudio 在打开解决方案时会尝试自动解析损坏的路径。当它这样做时，它不会告诉你它，通常不会改变你的解决方案和项目文件（这是你所希望的。）
尝试在文本编辑器中打开您的解决方案文件和/或项目文件，并确保所有相对路径都有效。
正如亚历克斯所说，我认为您的问题是 CC.NET 服务作为本地用户帐户运行。不幸的是，一些 C++ 环境变量是每个用户的，不会被转移到默认的构建环境中。在我的情况下，它是在Tools -> Options -> Projects and Solutions -> VC++ Directories中定义的 lib 和 include 文件。同样的问题显然会导致其他问题，并在本文中称为黄色块。
我的解决方案是在专门用于构建的构建机器上创建一个新用户（BuildUser ）。关键是然后以BuildUser身份登录并设置环境。最后，我将 CC.NET 服务更改为以 BuildUser 身份登录并重新启动它。
（重新发布，因为我最初的帖子似乎失败了）
VC2003 似乎在依赖和输入库之间存在不一致。
一个例子：
清理ProjectB时，A.lib不会被删除，ProjectB编译时也不会重建。因此，构建似乎在您的本地计算机上成功。
CC.NET 从头开始，构建失败，因为首先找不到 A.lib。