visual-c – 任务在CruiseControl.NET中成功进行MFC应用程序时失败了吗？

2019年8月1日 139次阅读

概述

我正在通过CruiseControl.net和VS2010开发MFC应用程序的持续集成版本.构建我的.sln时,“Visual Studio”CCNet任务(< devenv />)可以正常工作,但是一个简单的MSBuild包装器脚本(见下文)通过CCNet< 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,可以解决存在的任何路径/环境/配置状态问题.回想起来,这当然是有道理的.

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

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

点赞