Archive

Posts Tagged ‘Wix’

Musings on Wix

2009/11/18 Leave a comment

Like many developers, I tend to forget about the installation process. In the past, I have thrown the product over the wall and left the installation to process to someone else. I knew this practice was less than optimal, but it was what I had to work with. On my last project, I took ownership of the full process including installation. Given that I did not want to pay too much money for yet another copy of an installation-building product, I decided it was time to learn to use Wix. While I will not say that Wix is wonderful, the price is right and it is, in many ways, less frustrating than the commercial products.

Wix has the advantage that the installation builder is close to the Windows Installer database tables so the possibility of the tables not being built right is small. Wix’s advantage is also its disadvantage, in that the user must learn the Windows Installer before they can do much with Wix. I realized that the commercial GUI installation builders and the Visual Studio setup projects are masking a lot of information. I also discovered that many issues with past installations were due to a lack of knowledge about the Windows Installer because the GUI products made the whole process seem simple, which is as far from reality as can be.

On first look, starting a new installation project with Wix is an overwhelming task. As you begin to read the Wix documentation, you rapidly understand you will be creating many GUIDS and doing a lot of typing. I attempted to create an installation without reading the Windows Installer documentation. While it is possible to create a usable installation without aide of the installer documentation, having more than a glancing familiarity with the Windows Installer will certainly help you create better installations.

Wix has some tools that automate a lot of this process, but they should be avoided on the first attempt. I say avoid them, not because they are bad, but because they can easily put the user in the same place as the GUI installers; too much masking of what is really happening. Misusing the tools can cause many undesired side effects.

It took me two days to create a simple install that had sixty components, many of which were shared between the two installable features. That time included understanding how to create the Start Menu entries and populate all the fields in the Add/Remove/Programs table (keep in mind that Wix is the assembler level code of the installer and it does almost nothing for you automatically). After the two days, my install would correctly clean up upon “un-installation” so that there was no trace of the program left on the system (the complete cleanup is something that the installer documentation and the Wix developers stress). I have not yet attempted patches or upgrade installs and I suspect that I am violating installer rules such that these will not work; so more reading on major and minor upgrades.

I had to include the call of a managed code installer class (System.Configuration.Install.Installer). While this is a bit difficult, the hardest part was figuring out how to do it. The process is almost completely devoid of documentation. The first thing I had to get into my head was that calling the Installer class was really a managed custom action. As soon as you mention managed custom actions, many people form a defensive circle and tell you that you should not write one. Both the Wix developers and the Windows Installer team discourage their use, but they can be extremely useful and, when done correctly, do not violate any of the installer’s rules. We would all benefit from the Windows Installer team removing their heads from the sand and embracing managed custom actions or even better if they would create a standard action to call a managed Installer class, but I am not holding my breath. Anyway, a day later, I had the custom action working and correctly cleaning up upon product removal.

Advertisements
Categories: Windows Development Tags: ,