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

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 扩展名 .dlls 的 .exe）升级到 Visual Studio 2010，并且可以在开发人员机器上毫无问题地编译该应用程序。
• 现在我正在 CI 服务器环境中编译应用程序
• 我在构建服务器上完整安装了 VS2010 (Professional)。通过这种方式，我知道我需要的一切都在机器上（一种或另一种方式），并且这将与开发人员机器保持一致。
• VS2010 已正确安装在 CI 服务器上，devenv 任务按预期工作
• 我现在有一个包装器 MSBuild 脚本，它执行一些扩展版本处理，然后通过 MSBuild 任务为应用程序构建 .sln。
• 此包装脚本通过 CCNet 的 MSBuild 任务运行，并因上述错误而失败

简单的 MSBuild 包装器

<?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) 的支持，msbuilding 解决方案不应该非常接近于通过 Visual Studio 编译吗？

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

更新 1

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

解决方案

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

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

Answer 1

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

• 确保 CC.net 服务作为域用户运行（因此它可以访问网络资源）并且该用户具有与普通开发人员相同的权限。 CC.net 服务用户应该是唯一用户（不是开发人员之一）（我更喜欢以尽可能严格的权限运行 CC.net，以便在单元测试期间排除开发人员引起的错误。由于大多数开发人员都是开发 PC 上的管理员，这可能导致需要以管理员身份运行的代码。）

• 您是否以 CC.net 服务用户的身份安装了 VS2010？如果没有，请检查安装用户的环境设置——它可能需要为 CC.net 服务用户添加额外的路径设置。

• 打开 CC.net 控制台日志并将日志级别增加到最大，然后观察构建开始时会发生什么。这将是冗长的，但可以包含有关构建环境的有用详细信息。

• 当开发人员登录 CC.net 服务器、检查您的解决方案并在本地构建它时会发生什么。它是否正确构建？

• 过去，我发现有必要运行 Visual Studio（使用命令行参数）来构建解决方案，因为并非所有项目类型（尤其是非 WiX 安装程序项目）都有 msbuild 任务)。如果您在 CC.net 服务器上执行此操作会发生什么变化？