www.mwasoftware.co.uk

I have been using Installshield Express to install applications for more years than I care to remember. But I have never really been that happy with it and this year rather than paying up for yet another upgrade, I looked for an alternative. The alternative I found is called WiX. It is almost an oxymoron: an Open Source Product from Microsoft - and it's a great product. This blog is about why I have changed from Installshield to WiX and why WiX was used for the new versions of the Firebird Merge Modules.

Why Change?

The first reason was the usual one of cost. Installshield is not a cheap product and the even the entry level Express version seems to be getting more and more expensive - and the more powerful versions are just beyond our budget. But money isn't the only reason. In the end, money can always be found if the product is good enough and saves time and support. The problem is that Installshield didn't really do what I wanted it to do.

The first problem is that Installshield Express uses a binary file format for installation scripts. This is non-ideal for CVS style change control. When you have more than one variant of an application to install (as I do), it is easy enough to make a copy of a working installation script but thereafter it's just a headache keeping them in step when you need to make future changes.

Installshield also insists on using absolute path names for the files that you include in your installation - which is fine until you want to change the location of a file on your system, when you have to go back and change every place it is used.

The Installshield tree view of an installation looks nice - at first - but then like any attempt to present a database as a single tree view, it gets in the way as many times as it helps. Just consider the simple case of defining a short cut menu for an application executeable. Why is it in a separate place to where the application executeable is defined? Grouping short cuts together is one view on a database, while locating short cuts next to their targets is just as valid.

With the Express version you really are limited as the the dialogs and their sequence. I can't just add another minor dialog without upgrading to the more expensive version. 

And finally, Installshield Express is really just an editor for a Windows Installer database, but an editor that limits my access to Windows Installer. If I want to use additional functions then I have to upgrade to a more powerful and expensive version - and why is it that the feature I really want is never in the entry level version?

Basically, what I wanted was a means of creating a Windows Installer Database that:

  1. Uses text based scripts for easy use with CVS.
  2. Is modular in design so that I can easily cope with minor variations in an application - and reflects the structure of the application and its support components.
  3. Allows me to define the different parts of the installation (executables, short cuts, registry entries, etc.) in a way that reflects the way they relate to each other rather than be forced to use a single view on the database, and one that is oriented around the final outcome rather than its development.
  4. Allows easy modification of the paths to source files.
  5. Does not prevent me from using all of Windows Installer
  6. Allows me to customise the dialogs.
  7. Does not make me want to take deep breath when looking at the price.

The Search for a new Installation Script Preparation Tool

There are still several commercial alternatives to Installshield on the market, such as Wise and Installaware. However, none of them seemed to offer what I was looking for. On the other hand, a Wikipedia article on Windows Installer led me to WiX - and WiX was just what I was looking for.

Why WiX? Well:

  • It uses source scripts using an XML based grammar. Text based and so meets my first criteria.
  • The source scripts can be organised into many fragments and a preprocessor permits 'C' style conditional inclusion of components etc. i.e. its modular.
  • The use of XML and fragments gives great flexibility over how the components of each installation are defined. It is easy enough to define a component that consists of a file, a short cut and a registry entry all nicely grouped together in XML. On the other hand, you can keep them separate if you want to.
  • Environment variables as well as defined variables can be referenced in the scripts. These give a flexible means of defining things such as common root folders for the source files.
  • All Windows Installer functions are available.
  • Dialogs are all scripted and the scripts are available for modification. A WYSIWYG tool "WixEdit" is also available for dialog creation.
  • It's Open Source - need I say more.

Yes, I'm sold on WiX.

In practice, a WiX script is an XML representation of a Windows Installer database and the compilation and linking of the scripts is essentially a transform from the XML representation to a relational database - plus laying out the installation files for you. But, while a relational database is never easy to understand when looking at it "in the raw", an XML representation is much more meaningful.

WiX is not necessarily the right answer for everyone. If you are a novice programmer with a simple self-contained executable to install, then the versions of Installshield or Installaware packaged with Delphi are perfectly good enough. But if you are working on a larger product then you should really think about WiX. True, you need to understand Windows Installer concepts if you are to make use of WiX and an XML file can be a bit daunting at first sight. But there is a good online tutorial available, and the time spent learning to use WiX is well worth the effort.

WiX and the Firebird Merge Modules

Prior to using WiX scripts, the Merge Modules were created using Microsoft's ORCA tool. This tool allows you to create and edit Windows Installer databases, but is a low level tool and time consuming to use. It was OK for the first generation of Merge Modules, but as more requirements have come forward, such as the Classic as well as the Super Server, Windows Firewall configuration, Lock Down versions and more complicated upgrade cases, continuing to use ORCA just ceased to be a reasonable option.

With WiX, it has been possible to create a unified set of scripts for both Firebird 1.5.x and Firebird 2 and all the different variants of Server and Server Configuration. Conditional compilation is used to select the different variants. When a new version of Firebird comes out it should just be a simple case of minor changes to this set of scripts to reflect any new features, rather than having to author a new set of Merge Modules. Something that should really speed up the availability time.

Use of the Open Source WiX tool also makes it feasible to make available example installs using the Merge Modules, which can be downloaded and compiled by anyone. These examples may provide the basis of many end user Firebird Installs.

Enjoy using the Merge Modules and example scripts.

 
Tony Whyman, August 2007