Question

概述

我正在通过CruiseControl.net和VS2010开发MFC应用程序的持续集成版本。构建我的.sln时，“Visual Studio”CCNet任务（<devenv/>）可以正常工作，但是通过CCNet <msbuild/>任务运行的简单MSBuild包装器脚本（见下文）失败，错误如下：

错误RC1015：无法打开包含文件'winres.h'..
错误C1083：无法打开包含文件：'afxwin.h'：没有这样的文件或目录
错误C1083：无法打开包含文件：'afx.h'：没有此类文件或目录

问题

如何调整msbuild包装器的构建环境，以便正确构建应用程序？（很明显MFC路径不适合msbuild环境，但我如何修复MSBuild + VS2010 + MFC + CCNet？）

背景详情

我们已成功将MFC应用程序（带有一些MFC扩展名.dll的.exe）升级到Visual Studio 2010，并且可以在开发人员计算机上无问题地编译应用程序。
现在我正在编写CI服务器环境中的应用程序
我在构建服务器上完成了VS2010（Professional）的完整安装。通过这种方式，我知道我需要的一切都在机器上（不管怎样），这与开发者机器一致。
VS2010已正确安装在CI服务器上，devenv任务按预期工作
我现在有一个包装器MSBuild脚本，它执行一些扩展版本处理，然后通过MSBuild任务为应用程序构建.sln。
此包装脚本通过CCNet的MSBuild任务运行，并因上述错误而失败

简单的MSBuild Wrapper

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build"
   xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Build">
    <!-- Doing some versioning stuff here-->
    <MSBuild Projects="target.sln" 
      Properties="Configuration=ReleaseUnicode;Platform=Any CPU;..." />
  </Target>
</Project>

我的假设

这似乎是MFC说服的标准标头资源的包含路径的缺失/错误配置
我应该能够强制MSBuild环境来考虑我的VS2010安装中的相关资源文件并使这种方法有效。
鉴于vs2010 msbuild对visual c ++项目（.vcxproj）的支持，不应该通过visual studio编译解决方案吗？

但我该怎么做？我在设置环境变量吗？注册表设置？我可以看到在某些情况下如何注入其他目录，但这似乎需要在编译器默认级别进行更系统的配置。

更新1

这似乎只发生在两种情况：资源编译（rc.exe）和预编译头（stdafx.h）编译，并且只针对某些项目？我认为这是全面的，但事实上它似乎只是在这些情况下。我想我会继续挖掘并希望有人有一些他们愿意分享的见解......

解决方案

我进行了两次调整以使其正常工作。第一个是从我的解决方案中提取第三方项目并独立构建（它有大部分错误）。通过检入它的二进制文件到源代码控制（就像许多其他第三方库一样），我正在链接到它而没有问题。然而，正如许多人所指出的那样，这只是避免了这个问题。

偶然发现了解决方案的第二部分，但是W. Craig Trader的建议清单明确暗示了这一点。也就是说，我手动将源代码提取到服务器上的工作目录，并在visual studio中手动构建解决方案。通过为该ccnet服务用户实际启动visual studio，可以解决存在的任何路径/环境/配置状态问题。回想起来，这当然是有道理的。

Answer 1

有太多变量无法准确预测问题所在，但这里列出了我要检查/做的事情，以便将其运行到地面：

确保CC.net服务作为域用户运行（因此它可以访问网络资源），并且该用户具有与常规开发人员相同的权限。 CC.net服务用户应该是一个唯一的用户（不是开发人员之一）（我更喜欢运行具有最严格权限的CC.net，以便在单元测试期间消除开发人员引起的错误。由于大多数开发人员都是在他们的开发PC上的管理员，这可能导致需要以管理员身份运行的代码。）
您是否将VS2010安装为CC.net服务用户？如果没有，请检查安装用户的环境设置 - 可能需要为CC.net服务用户添加其他路径设置。
打开CC.net控制台日志记录并将日志级别提高到最大值，然后观察构建开始时会发生什么。这将是冗长的，但可以包含有关构建环境的有用详细信息。
当开发人员登录CC.net服务器，检查您的解决方案并在本地构建它时会发生什么。它是否正确构建？
过去，我发现有必要运行Visual Studio（使用命令行参数）来构建解决方案，因为没有针对所有项目类型的msbuild任务（特别是非WiX安装程序项目））。如果在CC.net服务器上执行此操作会有什么变化？

在<devenv>成功使用CruiseControl.NET中的MFC应用程序时，<msbuild>任务失败？</devenv> </msbuild>

1 个答案: