Distributed Setup Development Revisited

Last summer I wrote an article talking about the advantages and disadvantages of InstallShield versus Windows Installer XML and a Setup Democratization journey I was about to embark on. Nine months later the battle has been won and I have a few high level observations to report.

Distributed Setup Development Can Work

Back in 2005 I was involved in a distributed setup development environment that was a complete disaster. The combination of vdproj/installutil and poor software architecture choices had resulted in me being very jaded against the notion of sharing responsibility of developing setup with the developers. Unfortunately, the model of centralized setup development can only scale so far before the quality of the installer declines not because the setup developers don't know how to write good setup but because they just can't keep up with the sheer size of the application domain. They simply don't know enough to be able to help make good decisions. Eventually this becomes just as fatal as the very model that first jaded me into not sharing any responsibility.

In 2009 I found myself at this breaking point and decided to once again try setup democratization. This time, I wanted to find just the right blend between centralized and decentralized. I believe with WiX, InstallShield and a little out of the box thinking we've succeeded in doing just this and that we will be able to scale for many more years to come.

Visualization

One of the biggest problems developers had was they couldn't easily see into the structure of an installer or compare the installer to previous builds or other installers. Sure, I could try to teach them to use orca, perform administrative installs or do other tricks but what they really needed was a powerful "Google Earth" style tool that really lets them drill down through and search across to get situational awareness. Once they had this capability they could make better choices.

Simplification

Application developers don't have 6 months of free time to learn the Windows Installer . They need to be provided a short training session with an important set of rules to not break. The component rules can be basically explained by quoting The Highlander Movies: 'There can only be one.' Tell them that MSI is a declarative not imperative language. Relate it to things they understand like WPF and XAML. Explain to them to not ask for things like xcopy, regsvr32, regasm, gacutil or installutil. Instead ask them to ask for things at a higher level such as register a (un)managed file, deploy a file to the GAC or install/start a service. Finally provide tools that allow them to self-serve the majority of the heavy lifting: Files and Folders. Provide a tool that is simple to use yet still creates XML documents that follow the component rules and allow for adding in additional metadata by the setup experts. Finally, invest in making strong relationship with the developers. The setup developers will find themselves with more free time to go around and consult with the developers to help bridge the gap between application domain knowledge and setup domain knowledge. Both sides will gradually learn more about the other.

Validation

Entropy applies to setup. The best way to preserve the order that you fight so hard to create is to perform extensive validation with each build. Don't allow one mistake to build upon another. Fail the builds and get your problems fixed ASAP. Make the mistake bubble up to the developer in a way he will understand and know to not repeat.

WiX and InstallShield can Complement Each Other

Usually one thinks about WiX *VS* InstallShield. I now no longer see it this way. I now see it as WiX *AND* InstallShield. Each tool has strengths and weaknesses but blended together result in a very powerful platform. However, I do believe that is time for a fully functional InstallShield style IDE to be built upon the WiX schema. I openly hope that InstallShield will take this challenge. Until then I will be building IsWiX and I hope others will either join me.