There are many ways to run a find and replace in a config file to environmentalize it: you can update files in the build before they are compiled into the MSI, and even here there are multiple choices: SlowCheetah being one of them. This only works if you know at runtime the servers you are deploying to, or you only want a direct 1 to 1 connection. So on those occasions that you want to deploy to more than one box, updating at runtime does not work. Fortunately there is a way to update using WiX, and is surprisingly straightforward.

Your WiX project will need a reference to the WixUtilExtension dll. Within the Product.wxs file, within the “Feature” key value pair I added a ComponentRef and gave it the Id of “XmlUpdateConfig”.

<Feature Id="ProductFeature" Title="Red.Phoenix" Level="1">
<ComponentRef Id="XmlUpdateConfig"/>

I added a separate wxs file to the installer project.Below I will discuss the values you have to enter:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns=""
<DirectoryRef Id="WebBin">
<Component Id="XmlUpdateConfig"
Guid="{5AEF24F2-022C-4B19-8F44-91663AC2EB62}" >
<CreateFolder />
<util:XmlFile Id="DataServiceCommand"
Sequence="1" />
<util:XmlFile Id="DataServiceQuery"
Sequence="1" />

The two endpoint addresses I am editing look like this:

<endpoint address="net.tcp://localhost:809/Services/data/DataServiceCommand.svc" binding="netTcpBinding" bindingConfiguration="MarketTcp" contract="ServiceFacade.Interfaces.Service.MarketService" name="tcpMarketService" behaviorConfiguration="largeMessage" />
<endpoint address="net.tcp://localhost:809/Services/data/MarketDataQuery.svc" binding="netTcpBinding" contract="ServiceFacade.Interfaces.Service.DayService" name="tcpWorkingService" behaviorConfiguration="largeMessage" />

  • For DirectoryRef I am using the Id of the directory that the file will be deployed to as this will be completed after the InstallFiles task. I believe that this is implicit within WiX as I have not had to configure this like I would for a CustomAction.
  • The ComponentId is the same as the ComponentRefId in the product.wxs file.
  • For each value I want to update I have to give a unique name otherwise the installer will fail.
  • For each action I want I use the SetValue. SetValue sets the text value inside the node specified in ElementPath.
  • The Element path is an xpath to the value I want updated.
  • The Value is what I want updated. The values within square brackets are variables that I pass in when i run the “msiexec /i” command. So lt’s say this MSI was called WebService, the msiexec command would look like this:WixWednesday1_3_1
  • File pertains to the file location of the config file.
  • Other than “setvalue” it is also possible to edit the files in other ways using xpath:


Wow, something in WiX that is quick and simple and works well! Facetiousness aside, it’s very straightforward to update files on deployment and the more i think about it, the more sense it makes to use this method over any other method as it makes the MSI’s environment agnostic.


  1. Download WiX from CodePlex here.
  2. As I said, I don’t think the manual for WiX is all that great. It feels like it’s been written by an expert in WiX for an expert in WiX. But I guess at least there is a manual.
  3. There’s also a very comprehensive tutorial written about WiX that explains it in far greater detail than I have here. It also provides plenty of examples. Such as in the advanced sections there is a tutorial on creating your own custom UI.
  4. I’ve probably short-changed msiexec. Aside from running msiexec /? in the cmdline, there’s plenty of examples on the TechNet site.
  5. There’s even a book available! I’ve not read it, however the reviews on seem positive. For such an esoteric piece of software, and at a reasonable price it’s worth a go? Maybe I’ll buy it and review it at the end of this series….