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