Learn before Build

Buy vs. Build dilemma is quite common in software development. Based on degree of customization, decisions are made. But is it just degree of customization? As a developer, the urge to build and will to prove that “we can pull it off” is very strong. What I find often is that another dilemma exists, similar to the mentioned one, but rooted in restrictions related to time and will to go above the “regular known” – Learn vs. Build.

As an example, I can take WiX installer and build-server spawned off builds per environment. If you have multiple environments, normally we’d go with configuration-variables-per-environment (NAnt) file, that would get included during the build process and result in MSI installer preconfigured for that specific environment it was build for. Now, if you have 10 different environments, and about 10 different products you build often, it becomes a burden on build server and a very convoluted way of doing things on a large scale. What are the options? Several. Among those build more or learn about things and then make a decision.

Gladly, after learning a bit more about WiX, it is presently nice to know that WiX has the concept of parameters and XML poking baked straight in it. Now, making a single build to accommodate different environments became way simple – single installer with a batch/command file per environment (batch just would invoke MSI installer, passing in environment specific parameters).

To achieve the solution, add a reference to WixUtilExtension.dll and add a namespace for it as a Wix element attribute xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"

From that point, this is very similar to a standard XML poke (such as NAnt).

<util:XmlFile Id="SetKey1"
              Action="setValue"
              ElementPath="//appSettings/add[\[]@key='Location'[\]]/@value"
              Value="[LOCATION]"
              File="[#AppConfig]"
              SelectionLanguage="XPath"
              Sequence="1" />

A few things to explain:

#AppConfig – reference to the WiX included file ID, with # sign in front where XPath is executed

LOCATION – parameter passed into WiX MSI when executed

So if MSI generated by the build is called Product.msi, batch file could contain a line:

Product.msi LOCATION=C:\bla

Then result configuration file identified by “AppConfig” ID would contain:

<appSettings>
    <add key="Location" value="C:\bla" />

Note: if no parameters are supplied, empty string is used clearing any default values

Moral of this post? Invest some time before you rush to build. There’s a high potential that you are re-inventing the wheel. And another one, it is never too late to re-factor, if something just “doesn’t feel right”.