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

Question

我一直在进行我的持续集成项目的下一步，即获取 TeamCity构建我的应用程序，自动更改所有程序集的版本号，然后创建一个安装程序。

先说一点背景:

在过去的几个月里，我一直在成功运行 TeamCity，它构建了我的配置并很好地运行了我的 NUnit 和 NCover 测试。

我花了一点时间研究安装程序——我一直讨厌 InstallShield，并且从未考虑将它用于我当前的应用程序。我喜欢NSIS，但后来碰巧遇到了WiX .我对 MS Installer 架构没有任何深入的了解，我知道这对于复杂的项目是危险的，所以在某些时候我需要了解更多关于它的信息。然而，经过几天的 SO 问题、谷歌搜索和阅读博客后，我有一个 WiX 项目，它成功构建、安装、应用程序运行，并且一切都卸载干净。伟大的!

我还想让 TeamCity 构建配置自动更新我所有程序集的版本号。我可以通过安装 MSBuild Community Tasks 来模拟这个功能。在我的开发机器上，并创建一个使用 BeforeBuild 的部署配置目标和 FileUpdate更改版本号的任务。这工作正常，除了在我的开发机器上，我没有 build_vcs_number_1要替换的环境变量。

这就是我现在所处的位置——我需要让 TeamCity 进行更新，虽然它确实有 build_vcs_number_1环境变量，我不知道如何获得 WiX MSBuild 社区任务。

我读过的一篇文章建议将 MSBuild 目标 checkin SVN 文件夹。我有一个这样的/extlib 文件夹，所以我的 TeamCity VCS checkout 规则如下所示:

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

如何从环境变量访问 extlib？ 当我运行构建时，TeamCity 提示(并且正确地)它找不到 c:\wix30\MSBuildCommunityTasks .实际文件夹为 C:\TeamCity\buildAgent\work\3e073d2b74226378\extlib\wix30\MSBuildCommunityTasks .该文件夹是自动生成的，因为我正在执行服务器端结帐，因此必须有一些 TeamCity 设置的环境变量可以用来获取正确的路径。

我应该注意的一件事是，我已经进入了构建配置 -> 属性和环境变量，并找到了包含所有现有变量的不直观的下拉列表，并且没有看到任何听起来像指向工作路径的变量的东西。

我能想到的一种可能的解决方法是在构建服务器上安装 MSBuild 社区任务，然后我可以创建一个可由 <WixToolPath> 访问的系统环境变量。 .

有人有其他建议吗？

Answer 1

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

我做了类似的事情，但不是之前的构建目标，我有一个 msbuild 项目文件，大致如下:

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

我的 UpdateVersionNumbers 目标获取 SVN 修订版，然后使用正则表达式和 FileUpdate 任务将版本号的第 4 部分更改为 SVN 修订版。

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

不过，要回答您的其他一些问题:

指定路径时，请始终使用相对于解决方案根目录(结帐目录)的路径。因此，例如在这种情况下，您只需使用 wix30\MSBuildCommunityTasks . TeamCity 以工作目录作为根执行 msbuild，最重要的是，您或其他开发人员在哪里进行结帐并不重要 - 路径都是相对的。

您可以使用 Build Parameters -> System properties 将 teamcity 中的参数传递给 msbuild。例如，添加一个名为 agentHome 的属性值为 %system.agent.home.dir%然后您可以在您的 msbuild 文件中将其作为 $(agentHome) 引用。请注意，如果您还像上面的示例一样再次调用 msbuild，则必须执行以下操作:

  <MSBuild Projects="Project.sln" Properties="agentHome=$(agentHome)" Targets="Build"/>

将该变量实际传递到 Project.sln 中。我认为，但我并不肯定在 .sln 文件上运行的 msbuild 也会将所有属性传递给所有单个项目，因此您实际上可以在构建之前的事件中访问它。

关于安装程序的旁注(我最近经历了与您相同的事情):我选择了 WiX 3.0，虽然它有相当长的学习曲线，但它运行良好。我们开始了新的开发流程，并开始使用 VS2010 和 .NET 4。好吧，WiX 3.0 与 VS2010 不兼容，所以我们需要 WiX 3.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 ，但终于弄明白了。

尽管如此(在不兼容、不稳定的测试版(几个月前)和整体进展缓慢之间)的挫败感确实让我对 WiX 感到厌烦(对从事 WiX 工作的人没有冒犯，但我只想要一个安装程序而我不想要'不想参与其中。注意，他们也非常frustrated)。再加上我接下来需要的产品需要一个更复杂的安装程序，而 WiX 看起来工作量太大了。我刚刚使用 AdvancedInstaller 构建了我的安装程序，并且只用了几天，到目前为止一直运行良好(尽管我们现在还处于早期开发阶段，但开始持续部署和测试)。 AI 的定价是合理的(我们现在仍处于试用版)，但我将在接下来的几天内购买。

我敢肯定，我花在学习 AI 上的时间比我花在学习 WiX 上的时间要少得多，然后试着让它做我需要的一切。了解一些有关 Windows Installer 工作原理的知识是不可避免的，但您不必太深入。