代码之家 › 专栏 › 技术社区 › Dave

需要TeamCity+WiX+MSBuild工作流建议

msbuildcommunitytasks teamcity wix msbuild

Dave · 技术社区 · 14 年前

TeamCity 若要生成我的应用程序,请自动更改所有程序集的版本号,然后创建安装程序。

先来点背景:

在过去的几个月里,我成功地运行了TeamCity,它构建了我的配置,运行了我的NUnit和NCover测试。

WiX . 我对MS-Installer体系结构没有任何深入的了解,我知道它对于复杂的项目是危险的,所以在某个时候我需要了解更多。然而,经过几天的问答、谷歌搜索和阅读博客,我有了一个WiX项目,它可以成功地构建、安装、运行应用程序,并且所有东西都可以完全卸载。伟大的!

MSBuild Community Tasks 在我的开发计算机上,并创建使用 BeforeBuild 目标和 FileUpdate build_vcs_number_1 要替换的环境变量。

构建vcs编号环境变量,我不知道如何获取WiX MSBuild社区任务。

我读过一篇文章,建议将MSBuild目标签入SVN文件夹。我有一个/extlib文件夹来存放类似的内容,因此我的TeamCity VCS签出规则如下所示:

+:tags/2010-10-15=>src
+:extlib=>extlib

如何从环境变量获取extlib? c:\wix30\MSBuildCommunityTasks . 实际文件夹是 C:\TeamCity\buildAgent\work\3e073d2b74226378\extlib\wix30\MSBuildCommunityTasks . 文件夹是自动生成的,因为我正在执行服务器端签出,所以必须有一些TeamCity设置的环境变量,我可以使用它们来获得正确的路径。

我能想到的一种可能的解决方法是在构建服务器上安装MSBuild社区任务,然后我可以创建一个可以通过 <WixToolPath>

有人有其他建议吗?

2 回复 | 直到 14 年前

Community uzul 7 年前

我可以看到尝试在SVN中使用msbuild社区任务(以减少生成计算机的需求)的一些优点,但我个人只想将它们安装在服务器上。重要部分:更新生成服务器的文档以将安装列为先决条件。对我来说,我基本上在跨多个项目的每个msbuild和部署脚本中使用社区任务,因此将它们全部保存在SVN中有点多余。我还在生成服务器上安装了WiX。

<Target Name="Build">
    <CallTarget Targets="UpdateVersionNumbers"/>
    <MSBuild Projects="Project.sln" Targets="Build"/>
</Target>

My UpdateVersionNumbers目标获取SVN版本,然后使用regex和FileUpdate任务将版本号的第四部分更改为SVN版本。

然后我运行解决方案文件的正常构建,并在其中包含构建.wixproj。很简单,真的。

不过,要回答其他一些问题:

指定路径时,始终使用相对于解决方案根目录(checkout dir)的路径。所以在这种情况下,你只要 wix30\MSBuildCommunityTasks . TeamCity以working dir作为根目录执行msbuild,除此之外,您或其他开发人员签出到哪里并不重要-路径都是相对的。
可以使用生成参数->系统属性将teamcity中的参数传递给msbuild。因此,例如,添加一个名为 agentHome %system.agent.home.dir% 然后可以在msbuild文件中将其引用为$(agentHome)。注意,如果您还像我在上面的示例中那样再次调用msbuild,则必须执行以下操作:
```
  <MSBuild Projects="Project.sln" Properties="agentHome=$(agentHome)" Targets="Build"/>
```
将该变量实际传递到Project.sln。我但我不确定在.sln文件上运行的msbuild是否也会将所有属性传递给所有单个项目,以便您可以在before build事件中实际访问它。

关于安装程序的附带说明(我最近也经历了同样的事情):我决定使用WiX 3.0,尽管它有相当的学习曲线,但它工作得很好。我们开始了新的开发流程,并开始使用VS2010和.NET 4。好吧,WiX 3.0与VS2010不兼容,所以我们需要wix3.5(它仍然在Beta版中——尽管 state of it seems much better now than it was a few months ago ,但它们仍然落后。有时候,这就是开源的本质。我吃了一些 pain getting WiX 3.0 and 3.5 to install together

不过,这种挫折感(在不兼容、不稳定的beta(几个月前)和整体缓慢的进展之间)真的让我关闭了WiX(对WiX的工作人员没有冒犯,但我只是想要一个安装程序,我不想参与其中。注意,他们非常 frustrated 也一样)。另外,我下一步需要的产品需要一个更复杂的安装程序,而WiX看起来工作太多了。我刚用 AdvancedInstaller ,只花了几天时间,到目前为止运行良好(尽管我们现在只是处于早期开发阶段,但开始了连续的部署和测试)。人工智能的价格是合理的(我们现在仍在试用版),但我将在未来几天购买。

我确信我花在学习人工智能上的时间比我花在学习WiX上的时间要少得多,然后试着让它做我需要的一切。了解Windows安装程序的工作原理有点不可避免,但您不必太深入。

Dave 14 年前

我讨厌发生这种事。。。输入一个很长的问题,但几分钟后却发现我漏掉了一些东西。

alt text

我想我现在的问题是--我可以在我的.wixproj中使用%system.agent.work.dir%吗?我现在就试试。