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

Question

我一直致力于持续集成项目的下一步,即让TeamCity构建我的应用程序,自动更改所有程序集的版本号,然后创建安装程序.

首先是一点背景:

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

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

我还想让TeamCity构建配置自动更新所有程序集的版本号.我能够通过在我的开发机器上安装MSBuild社区任务并创建使用BeforeBuild目标和FileUpdate任务来更改版本号的部署配置来模拟此功能.这是正常的,除了在我的开发机器上,我没有替换build_vcs_number_1环境变量.

这就是我现在的位置 - 我需要让TeamCity进行更新,虽然它确实有build_vcs_number_1环境变量,但我无法弄清楚如何进入WiX MSBuild社区任务.

我读过的一篇文章建议将MSBuild目标检入SVN文件夹.我有一个/ extlib文件夹用于这样的事情,所以我的TeamCity VCS结帐规则看起来像这样:

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

如何从环境变量获取extlib？ 当我运行构建时,TeamCity会抱怨(并且正确地)它无法找到c:\wix30\MSBuildCommunityTasks.实际的文件夹是C:\TeamCity\buildAgent\work\3e073d2b74226378\extlib\wix30\MSBuildCommunityTasks.该文件夹是自动生成的,因为我正在进行服务器端检出,因此必须有一些TeamCity设置的环境变量,我可以使用它来获取正确的路径.

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

我能想到的一种可能的解决方法是在构建服务器上安装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 任务将版本号的第四部分更改为 SVN 修订版。

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

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

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

• 您可以使用“构建参数”->“系统属性”将 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 阶段 - 尽管它的状态现在看起来比以前好得多）是几个月前的事了，但他们仍然落后。有时这就是开源的本质）。我在将 WiX 3.0 和 3.5 安装在一起时遇到了一些麻烦，但最终还是弄清楚了。

不过，这种挫败感（不兼容、不稳定的测试版（几个月前）和整体缓慢的进展）确实让我放弃了 WiX（无意冒犯 WiX 的工作人员，但我只想要一个安装程序，但我不想要）不想参与其中。注意，他们也非常沮丧）。除此之外，我接下来需要的产品需要更复杂的安装程序，而 WiX 似乎工作量太大了。我刚刚使用AdvancedInstaller构建了我的安装程序，只花了几天时间，到目前为止一直运行良好（尽管我们现在还处于早期开发阶段，但已开始持续部署和测试）。AI 的定价很合理（我们现在仍处于试用版），但我将在接下来的几天内购买。

我确信我花在学习 AI 上的时间比我花在学习 WiX 上的时间要少得多，然后试图让它做我需要的一切。了解 Windows Installer 的工作原理是不可避免的，但您不必太深入。