需要的TeamCity +维克斯+的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环境变量，我无法弄清楚如何在维克斯的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设置的可用于获取正确路径的环境变量。

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

我能想到的一种可能的解决方法是只在生成服务器上安装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。很简单，真的。

---

要回答你的一些其他问题，但：

• 在指定的路径，通常使用相对于您的解决方案（结帐DIR）的根路径。因此，例如在这种情况下，您只需使用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也会将所有属性传递给所有单个项目，因此您可以在生成事件之前实际访问它。在安装

---

附注（我最近通过你做了同样的事情）：我看中了维克斯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工作者来说没有任何意义，但我只是想要一个安装程序我不想让这个参与进来。请注意，他们也非常的frustrated）。除此之外，我接下来需要的产品需要更复杂的安装程序，而WiX的工作似乎太多了。我使用AdvancedInstaller构建了我的安装程序，只花了几天时间，到目前为止一直运行良好（尽管我们现在只处于早期开发阶段，但开始持续部署和测试）。 AI的定价是合理的（我们现在还在试用版），但我会在接下来的几天内购买。

我很确定我花在学习AI上的时间比我花在学习WiX上的时间少得多，然后试图让它做我需要的一切。学习有关Windows Installer如何工作的SOMETHING有点不可避免，但您不必深入了解。

Answer 2

我恨它，当这种情况发生......键入一个长期的问题，只有找到的东西，后来我错过分钟。

我不知道这是它：

我想我现在的问题是 - 我能实际上我.wixproj使用％system.agent.work.dir％？我现在就试一试。