Is anybody running a WiX packaging step from Octopus?

Legacy Uncategorised
1

I"m working on a new product that we’re going to be throwing some MSI installers up on the web. We have multiple clients and environments and ideally I want the build system to build our code, then use Octopus to change our app.config for the environment/client and then run the WiX build to package it all up before FTPing it to it’s destination. Any tips from anybody who has done something similar?

2

Check the environment with PowerSHell script and then run msi installer for the current environment (just name the msi installers different)

3

That’s not a bad idea. Bloats my Nuget package size a bit since I need multiple installers in it but it works. Thanks.

4

Instead of putting multiple installers in your nuget (I"m assuming for different environments), how about having your WiX accept command line arguments and then adjust the app.config on the fly? You can use XmlPeek and XmlPoke WiX commands.

It’s been a long time since I’ve used WiX but I do have one project that is just migrating off of it to Octopus Deploy and I can look around there to refresh my memory if you would like some more suggestions.

5

Hi Mike,

I’ve had a similar scenario in the past and was surprised by how easily WiX can be added into this stage of the process. Compared to setting up your MSBuild environment on build agents, WiX is straightfoward.

I start by getting my WiX project up and running and compiling successfully from Visual Studio. The Build output window gives me the exact commands for Candle.exe (WiX compiler) and Light.exe (Linker).

My deployment steps consist of

  1. A PowerShell script that reads the existing App.config as an XML object. Transform the XML object in memory using Octopus Deploy variables and finally write the updated App.config back into place.

  2. A PowerShell script that executes the appropriate Candle and Light commands with command line arguments. (Check out Paul’s blog post on executing with dynamic parameters, link below)

The only part of the process I can’t speak to is the OctoPack / Nuget packaging between build server and Octopus Deploy. This was harder than I had anticipated but was driven by infrastructure, particularly network separation issues. My advice here is don’t underestimate how you get your build artifacts from the build server to the Octopus Deploy process.

From memory, I ended up using a zip file which was produced by the build server and was retrieved from the build server by the tentacle as an initial deployment step.

If you find yourself dynamically generating additional files during the MSI creation my advice would be:

  1. Avoid it where ever possible, it can lead to development issues where some of your runtime resources are only generated by the MSI packaging process. These resources typically need to be available for development and having developers install an incomplete version of the MSI just to gain these additional resources is cumbersome and problematic (especially during a spike or high level of churn)

  2. I you can’t avoid it, check out Paraffin which really helped us with this problem.

All the very best with the new project!

Matt