概述
我正在通过CruiseControl.net和VS2010进行MFC应用程序的持续集成构建。在构建我的.sln时，一个“Visual Studio” CCNet任务（<devenv/>）可以工作，但是通过CCNet <msbuild/>任务运行的简单MSBuild包装器脚本（见下文）会出现错误，如：
- error RC1015：无法打开包括文件“winres.h”。。
- error C1083：无法打开包括文件：“afxwin.h”：没有那个文件或目录
- error C1083：无法打开包括文件：“afx.h”：没有那个文件或目录
问题
如何调整我的msbuild包装器的构建环境，以便正确构建应用程序？（很明显，对于MSBuild + VS2010 + MFC + CCNet，MFC路径不正确，但是我该如何修复它？）
背景详细信息
- 我们已成功将一个MFC应用程序（.exe和一些MFC扩展.dll）升级到Visual Studio 2010，并且可以在开发人员机器上编译应用程序而无需任何问题。
- 现在，我正在尝试在CI服务器环境中编译应用程序
- 我在构建服务器上进行了完整的VS2010（专业版）安装。通过这种方式，我知道机器上需要的一切都会有（以某种方式），并且这将与开发人员机器保持一致。
- 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）编译，并且仅适用于某些项目？我曾认为它是全面的，但实际上只有在这些情况下才会发生。我想我会继续挖掘并希望有人愿意分享一些见解...
解决方案
我进行了两个调整以使其正常工作。首先是从我的解决方案中拉出一个第三方项目并独立构建它（它有大量错误）。通过将其二进制文件检入源代码控制（像许多其他第三方库一样），我可以无问题地链接到它。但是，正如许多人指出的那样，这只是避免问题。
解决方案的第二部分是偶然发现的，但由W. Craig Trader的建议清单明确暗示。也就是说，我手动将源代码拉到服务器的工作目录中，并在Visual Studio中手动构建了解决方案。实际上为ccnet服务用户启动Visual Studio消除了存在的任何路径/环境/配置状态问题。回想起来当然很有道理。