概述
我正在通过CruiseControl.net和VS2010进行MFC应用程序的持续集成构建。在构建my.sln时,一个“visualstudio”CCNet任务(
<devenv/>
)工作正常,但通过CCNet运行一个简单的MSBuild包装器脚本(见下文)
<msbuild/>
-
错误RC1015:无法打开包含文件“winres.h”。。
-
错误C1083:无法打开包含文件:“afxwin.h”:没有这样的文件或目录
-
错误C1083:无法打开包含文件:“afx.h”:没有这样的文件或目录
问题
如何调整msbuild包装器的生成环境,以便正确生成应用程序(很明显,MFC路径不适合msbuild环境,但是如何修复msbuild+VS2010+MFC+CCNet的路径?)
-
我们已经成功地将MFC应用程序(.exe和一些MFC扩展名.dll)升级到VisualStudio2010,并且可以在开发人员机器上编译应用程序而不会出现问题。
-
现在我正在CI服务器环境中编译应用程序
-
我在构建服务器上完整安装了VS2010(Professional)。通过这种方式,我知道我所需要的一切都会在机器上(以这种或那种方式),并且这与开发人员机器是一致的。
-
-
我现在有了一个包装器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说服的标准头资源的include路径的丢失/错误配置
-
我应该能够强制MSBuild环境考虑VS2010安装中的相关资源文件,并使此方法起作用。
-
但我该怎么做呢?我正在设置环境变量吗?注册表设置?在某些情况下,我可以看到如何注入额外的目录,但这似乎需要在编译器默认值级别进行更系统的配置。
更新1
这似乎只有在两种情况下才会发生:资源编译(rc.exe)和预编译头(stdafx.h)编译,而且只适用于某些项目?我认为这是全面的,但事实上,它似乎只是在这些情况下。我想我会继续挖掘,希望有人有一些见解,他们愿意分享。。。
我做了两个调整来让它工作。第一种方法是从我的解决方案中提取第三方项目并独立构建它(其中错误最多)。通过将它的二进制文件签入到源代码管理中(就像许多其他第三方库一样),我可以毫无疑问地链接到它。然而,正如许多人所指出的那样,这只是对问题的回避。
这个解决方案的第二部分是偶然发现的,但是在W。Craig Trader的建议。也就是说,我将源代码手动拉入服务器上的工作目录,并在visualstudio中手动构建解决方案。无论存在什么路径/环境/配置状态问题,都可以通过为ccnet服务用户实际启动visualstudio来解决。回想起来,这当然是有道理的。
