I’ve long been unimpressed by InstallShield. Ok, that’s slightly unfair, what I should say is that I’ve been unimpressed that it is different to all my other Visual Studio projects and that it costs quite a bit to purchase. So I went looking for an alternative. I’d previously played around a bit with the installation projects that come with Visual Studio and they seemed very clumsy and unintuitive to use so I had a look to see if they’d improved them. What I found was a project from Microsoft, if not officially a Microsoft Product, called
WiX or Windows Installer XML. I downloaded the latest v3 build and ran through the v2 tutorial. So what is it? It has the feel of a cross between an XML build script and a web page. The package of items you want to install are laid out in a hierarchical fashion loosely modeled on the resulting folders. You can then put in all the usual features (such as shortcuts, DLLs, documents, etc) into components that will be installed in these folders. I found it very easy to produce and the XML schema makes a lot of sense. It wasn’t without hiccups, my first problem was with shortcuts. Since I was using v3 I could build the project from Visual Studio rather than using all those nasty command line instructions – how quaint ;). The errors produced were quite good, at least they pointed to the correct line (see my complaints about Mono). However, it complained that my shortcut wasn’t advertised so should have an entry in the registry. Umm, ok. ‘Advertisement’ installer speak for presenting information about the item to be installed so it was my ignorance of MSI that didn’t help here. But I didn’t want to play with the registry (event though I just needed to put an value where it was asking for one) but luckily there is an attribute called "Advertise" on the shortcut element, so I went ahead and set it to ‘yes’. Not really sure what I’m doing here but hey it worked! The next problem was altogether harder to solve, and think it is a bug. The build kept complaining that the Program Files folder didn’t have an entry in the remove files table. This highlights one of the problems with WiX. The compilation errors are coming from the compilers that are producing the eventual MSI and the error messages are, reasonably, related to that. However, the WiX hides all these weird tables from the author so the error looks very odd. Fortunately I did know a little bit about this and after playing with a RemoveFolder element (only by "incorrectly" setting its overriding folder property) did I manage to finally build the installer. I ran it and without any UI the files I wanted to install were there in the correct places…better than my first few attempts with the Visual Studio installer projects. The next stage was to provide some for of UI that you’d expect from an installer. This is were the default features of WiX come into their own. By simply adding a single UI element (with a few default UI types) and adding a reference to the WiX UI dll the installer suddenly had all the usual features, license statements, custom|full|typical, etc, etc. Well sort of. The compiler through a fit when I first added the reference and chucked out hundreds of error message all seemingly about localized values. So I set the culture in the project properties but that didn’t seem to work, foxed I went to the web. Turns out there is a problem with saving the project culture properties and you have to unload the project, edit the project xml and reload it again. That worked and the installer with all the nice installer wizard pages sprang into life.
I’ve yet to test creating your own UI and installing some of the slightly odd things that I need to do (e.g. COM+, Services, etc) but so far I’ve been impressed, if slightly concerned about the support for the project – but, as I’ve not mentioned, you can download all the source so if the problem needs to be fixed the option is always there to just fix it yourself. Hopefully I’ll have some more time to complete my testing and start using it soon.
Summary of advantages:
1. It is free!
2. The installer project can live in the Visual Studio solution like all the other assets
3. Easy to produce, XML structure simple to use and the Visual Studio support is basic but good enough
4. Since it’s XML it should be easy to automatically construct the files based on the other projects in a solution
5. You have the source code
Disadvantages:
1. v3 is a Beta product
2. You have the source code 😉
3. You have to re-write DLLs to create new UI components, I’d have preferred to have a separate Visual Studio template for this.
4. Where is the support forum? Again another horrible mailing list only project. Come on people this isn’t the 80’s.