需要TeamCity + WiX + MSBuild工作流程建议 [英] TeamCity + WiX + MSBuild workflow suggestions needed

问题描述

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

I've been working on the next step of my continuous integration project, which is to get TeamCity to build my application, automatically change the version number of all assemblies, and then create an installer.

首先要有一些背景知识

在过去的几个月中，我一直成功运行TeamCity，它可以构建我的配置并运行我的NUnit和NCover测试.

I've been running TeamCity successfully for the past several months, and it builds my configurations and runs my NUnit and NCover tests just fine.

我花了一些时间研究安装程序-我一直讨厌InstallShield，从没考虑过将其用于当前应用程序.我喜欢NSIS，但随后碰巧遇到了 WiX .我对MS Installer架构没有任何深入的了解，我知道这对于复杂的项目是危险的，因此在某个时候，我需要学习更多有关它的知识.但是，经过几天的SO问题，谷歌搜索和阅读博客，我有了一个WiX项目，该项目成功构建，安装，运行应用程序，并且一切都干净地卸载了.太好了！

I took a little time researching installers -- I have always hated InstallShield and never considered it for my current application. I like NSIS, but then happened to come across WiX. I don't have any intimate knowledge of the MS Installer architecture, which I understand is dangerous for complicated projects, so at some point I'll need to learn more about it. However, after a few days of wading through SO questions, googling, and reading blogs, I have a WiX project that successfully builds, installs, the application runs, and everything uninstalls cleanly. Great!

我还想让TeamCity构建配置自动更新我所有程序集的版本号.我可以通过在开发计算机上安装 MSBuild社区任务并创建部署配置来模拟此功能.使用 BeforeBuild 目标和 FileUpdate 更改版本号的任务.正常运行，除了在我的开发机器上，我没有

I also wanted to have the TeamCity build configuration automatically update the version number of all of my assemblies. I was able to mock up this functionality by installing the MSBuild Community Tasks on my development machine, and creating a Deployment configuration that uses a BeforeBuild target and the FileUpdate task to change the version number. That works properly, except that on my development machine, I don't have a build_vcs_number_1 environment variable to substitute.

这就是我现在的位置-我需要让TeamCity进行更新，尽管它确实具有

So that's where I am now -- I need to have TeamCity do the update, and while it does have the build_vcs_number_1 environment variable, I can't figure out how to get at the WiX MSBuild Community Tasks.

我读了一篇推荐阅读的文章，建议将MSBuild目标检入到SVN文件夹中.我有一个/extlib文件夹来存放类似这样的内容，所以我的TeamCity VCS结帐规则如下所示:

One post I read recommended checking in the MSBuild targets into an SVN folder. I have an /extlib folder for things like this, so my TeamCity VCS checkout rules look something like this:

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

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

How do I get to extlib from an environment variable? When I run the build, TeamCity complains (and correctly so) that it can't find c:\wix30\MSBuildCommunityTasks. The actual folder is C:\TeamCity\buildAgent\work\3e073d2b74226378\extlib\wix30\MSBuildCommunityTasks. The folder is auto-generated since I'm doing a server-side checkout, so there must be some environment variable that TeamCity sets that I can use to get the correct path.

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

One thing I should note is that I've gone into the build configuration -> Properties and Environment Variables and found the unintuitive droplist with all existing variables, and didn't see anything that sounded like a variable that points to the work path.

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

One possible workaround I can think of is to just install MSBuild Community Tasks on the build server, and then I can create a system environment variable that can be accessed by <WixToolPath>.

还有其他建议吗?

推荐答案

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

I can see some merit in trying to have the msbuild community tasks in SVN (to reduce the requirements of a build machine) but personally I'd just install them on the server. Important part: update your documentation for your build server to list installing that as a pre-requisite. For me, I use the community tasks in basically every msbuild across several projects, and deployment scripts, so keeping them all in SVN is a bit redundant. I also have WiX installed on the build server.

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

I do something similar, but rather than a before build target, I have an msbuild project file roughly like this:

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

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

My UpdateVersionNumbers target grabs the SVN revision, and then uses a regex and FileUpdate task to change the 4th part of the version number to the SVN revision.

然后，我运行解决方案文件的常规构建，并且其中包括构建.wixproj的内容.真的很简单.

Then I run the normal build of the solution file, and included in that it builds the .wixproj. Pretty simple, really.

但是要回答您的其他一些问题:

To answer some of your other questions though:

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

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

• When specifying paths, always use paths relative to the root of your solution (checkout dir). So eg in this case, you'd just use wix30\MSBuildCommunityTasks. TeamCity executes msbuild with the working dir as the root, and on top of that, it doesn't matter where you or other developers do their checkout to - the paths are all just relative.

• You can pass parameters in teamcity to msbuild using the Build Parameters -> System properties. So eg, add a property called agentHome that has a value of %system.agent.home.dir% and then you can reference it in your msbuild file as $(agentHome). Note if you're also invoking msbuild again as in my example above, you'd have to do:

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

实际上将该变量传递到Project.sln.我认为，但我不能肯定在.sln文件上运行的msbuild还将所有属性传递给所有单独的项目，因此您实际上可以在before build事件中访问它.

to actually pass that variable into Project.sln. I think but I'm not positive that msbuild running on a .sln file will also pass all the properties to all the individual projects, so you can actually access it in your before build event.

关于安装程序的附带说明(我最近经历了与您所做的相同的事情):我选择了WiX 3.0，尽管有很多学习过程，但效果很好.我们开始了新的开发流程，并开始使用VS2010和.NET4.好吧，WiX 3.0与VS2010不兼容，因此我们需要WiX 3.5(仍处于Beta版-尽管痛苦地使WiX 3.0和3.5一起安装 ，但最终还是弄清楚了.

Side note on installers (I recently went through the same thing you did): I settled on WiX 3.0, and though there's quite the learning curve to it, it works well. We started a new stream of development, and started using VS2010 and .NET 4. Well, WiX 3.0 is not compatible with VS2010, so we needed WiX 3.5 (which is still in Beta - though the state of it seems much better now than it was a few months ago, but they are still lagging. Such is the nature of open source, sometimes). I had some pain getting WiX 3.0 and 3.5 to install together, but did finally figure it out.

尽管如此(在不兼容，不稳定的beta(几个月前)和总体进展缓慢之间)的挫败感确实使我无法使用WiX(对从事WiX的人员来说并没有冒犯，但我只想要安装程序和我不想参与其中.请注意，他们非常感到沮丧).另外，我接下来需要的产品需要更复杂的安装程序，而WiX似乎工作量太大.我刚刚使用 AdvancedInstaller 构建了安装程序，只用了几天，到目前为止，它一直在工作很好(尽管我们现在才处于开发的早期阶段，但是开始进行持续的部署和测试). AI的价格合理(我们现在仍处于试用版)，但我将在未来几天内购买.

The frustration of this though (between incompatibility, flaky betas (from a few months ago), and the overall slow progress) really turned me off WiX (no offense to the guys working on WiX, but I just want an installer and I don't want to get that involved. Note, they are very frustrated too). Add to that the product I need it for next requires a much more complex installer, and WiX just seems like way too much work. I just built up my installer using AdvancedInstaller, and it only took a couple days, and so far has been working well (though we're just in early dev stages now, but starting continuous deployment and testing). AI's pricing is reasonable (we're still in trial version now) but I'll be buying in the next couple days.

我可以肯定的是，我花在学习AI上的时间比花在学习WiX上的时间要少得多，然后再尝试使其能够完成我需要的一切.学习Windows Installer的工作原理有些无可避免，但是您不必太深入.

I'm SURE the time I spent learning AI was MUCH less than I'd spend learning WiX, and then trying to make it do everything I need. It is a bit unavoidable to learn SOMETHING about how Windows Installer works, but you don't have to get too in-depth.

这篇关于需要TeamCity + WiX + MSBuild工作流程建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！