需要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目标检入SVN文件夹。我有一个/ extlib文件夹用于这样的事情，所以我的TeamCity VCS结帐规则看起来像这样：

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

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

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

我能想到的一个可能的解决方法是在构建服务器上安装MSBuild社区任务，然后我可以创建一个可由C:\TeamCity\buildAgent\work\3e073d2b74226378\extlib\wix30\MSBuildCommunityTasks访问的系统环境变量。

有没有人有其他建议？

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。很简单，真的。

---

回答你的一些其他问题：

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

• 您可以使用Build Parameters - ＆gt;将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（它仍处于测试阶段 - 虽然是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的定价是合理的（我们现在仍处于试用版），但我会在接下来的几天内购买。

我确定我花在学习人工智能上的时间远远少于我花在学习WiX上的时间，然后试图让它做我需要的一切。学习有关Windows Installer如何工作的SOMETHING有点不可避免，但您不必太深入。

Answer 2

我讨厌发生这种情况......输入一个很长的问题，只是为了找到我几分钟后遗漏的东西。

我想知道是不是这样：

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