Necessary wishes TeamCity + WiX + MSBuild

Question

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

First, a little background:

I have successfully launched TeamCity over the past few months, and it builds my configurations and performs NUnit and NCover tests perfectly.

I spent a little time learning installers - I always hated InstallShield and never reviewed it for my current application. I like NSIS, but then came across WiX . I do not have an intimate knowledge of the MS Installer architecture, which, as I understand it, is dangerous for complex projects, so at some point I will need to learn more about this. However, a few days after going through SO questions, searching the Internet and reading blogs, I have a WiX project that successfully creates, installs, runs the application and deletes everything cleanly. Fine!

I also wanted the TeamCity build configuration to automatically update the version number of all my builds. I was able to combine this functionality by setting BeforeBuild and FileUpdate to change the version number. This works correctly, except that on my development machine I don't have build_vcs_number_1 to replace.

So, when I am now - I need TeamCity to perform the update, and although it has the build_vcs_number_1 environment variable , I cannot figure out how to access the tasks of the WiX MSBuild community.

In one post I read, it is recommended to check the MSBuild targets in the SVN folder. I have a / extlib folder for such things, so my TeamCity VCS validation rules look something like this:

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

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

One thing that I should note is that I went into the assembly configuration -> Properties and environment variables and found an unintuitive droplist with all existing variables and did not see anything that sounded like a variable indicating the path worked.

One possible solution that I can think of is to simply set up the MSBuild community tasks on the build server, and then I can create a system environment variable that can be accessed by <WixToolPath> .

Does anyone have any other suggestions?

Answer 1

I see some advantages in trying to install the msbuild community tasks in SVN (to reduce the requirements for the build machine), but personally I just installed them on the server. The important part: update your documentation for your build server to indicate how to do this. For me, I use community tasks, basically, each msbuild file for several projects and deployment scenarios, so saving them to SVN is a bit redundant. I also have WiX installed on the build server.

I am doing something similar, but instead of the goal before the build, I have the msbuild project file something like this:

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

My goal, UpdateVersionNumbers, captures the revision of SVN, and then uses the regex and FileUpdate task to change the fourth part of the version number in the SVN editor.

Then I start the normal assembly of the solution file and include in it builds .wixproj. Pretty simple, really.

---

To answer some of your other questions:

• When specifying paths, always use paths relative to the root of your solution (checkout dir). So, for example, in this case you just use wix30\MSBuildCommunityTasks . TeamCity launches msbuild with the working directory as the root, and besides, it doesn’t matter where you or other developers perform their check - all paths are relative.

• You can pass parameters to teamcity in msbuild using the properties Build Parameters -> System. For example, add a property called agentHome that has the value %system.agent.home.dir% , and then you can refer to it in the msbuild file as $ (agentHome). Note that if you call msbuild again, as in my example above, you will need:

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

  to pass this variable to Project.sln. I think, but I'm not sure that msbuild running in a .sln file will also pass all properties to all individual projects so that you can access it in your event before building.

---

Side note to the installers (I recently went through the same thing as you): I settled on WiX 3.0, and although it has a pretty learning curve, it works well. We started a new development flow and started using VS2010 and .NET 4. Well, WiX 3.0 is not compatible with VS2010, so we need WiX 3.5 (which is still in beta, although the state seems much better than it was a few months ago , but they are still lagging. Sometimes this is the nature of open source). I had some pain in which WiX 3.0 and 3.5 installed together , but finally figured it out.

However, the disappointment of this (between incompatibility, flaky betas (from a few months ago) and general slow progress) really disabled WiX (don't be offended by the guys working on WiX, but I just want the installer and I don’t want to participate in it. Note, they are very frustrated too). Add to this the product that I need for the next one, it requires a much more complex installer, and WiX just seems like too much work. I just created my installer using AdvancedInstaller , and it only took a couple of days, and still worked fine (although we are now only in the early stages of development, but starting with continuous deployment and testing). AI pricing is reasonable (we're still in trial), but I will buy in the next couple of days.

I am SURE that the time spent learning AI was much less than what I spent learning WiX, and then tried to do everything I needed. It’s a little inevitable to learn how the Windows Installer works, but you don’t need to go too deep.

Answer 2

I hate when this happens ... enter a long question, only to find what I missed in a few minutes.

Interestingly, this is it:

I guess now my question is: can I use% system.agent.work.dir% in my .wixproj? I will try now.