Lifestyle of the MSIdle

What are the common install tasks?

Out-of-the-box (meaning the default Basic MSI project) your Basic MSI installer project is already capable of handling most of the standard installation actions. But what are some of the common features that you might want to add to the installer project -- and how might you do it?

Here are some of the things I've run into. If you have suggestions of common tasks like this, please leave a comment about it.

• Path validation. The user enters a path in the destination dialog and the built-in dialog will automatically prevent them from entering an invalid path. That's good, but what if a user choose a path like C:\, or C:\Windows? These probably are not smart places to install the product. Another problem is path length. If your have subdirectories that get created under the install directory, then what looks like a valid path length may actually turn out to be too long once the full subdirectory and filenames get put together. Bottom line - I find it useful to be able to validate the path that the user enters on the Destination Dialog and then prompt them for a better path if it fails validation.
• Cleanup user data on uninstall. The uninstall is automatically capable of removing any items that it originally installed. What if your product creates some sort of user data over time (history, configuration data, etc.)? In that case, the uninstall will not know about those items and won't remove them. Best practice would be to totally clean up at uninstall any items that your product put on the machine. (I like to refer to leftover items after uninstall as 'hanging chads'). So you will need a method to cleanup those hanging chads at uninstall time.
• Advanced Cleanup user data on uninstall. Once you've added the cleanup feature, I guarantee that somebody is going to come up with a reason why under some conditions the user will NOT want to cleanup all the user data. So the very next request that will come your way is... Make the cleanup of user data an option for the user to decide at uninstall time. NOTE: You will want to make the default be that it leaves the custom data so that you can support the next feature in the list.
• Port user data on upgrade. This is a common scenario and it is related to the above two items. When doing a major upgrade it will uninstall the old version and it does so silently (with no UI). Often the user may have customized some portion of the product and it is desirable for that customized information to get carried forward to the new version. Because uninstall may very well remove some of those customized items, you will need a method of backing up that data before uninstall, then restoring it after installation of the new version.
• Perform different upgrade tasks depending on which version you are upgrading from. Sometimes it seems that users tend to hold on to old versions of the software as long as they can. This can create a situation where you end up having to support upgrading from several different versions of the product, perhaps going back a couple years. Oftentimes you will need to run a certain upgrade task if you are upgrading from version 1 and a different task if upgrading from version 2.
• Require user to install to same directory on upgrade. This is fairly common. Even though a major upgrade uninstalls the old version, there may be good reasons why it is wise to reinstall to the same directory. One good reason: customized user data gets left behind in the old install directory and it saves having to copy it to a new location. So.. you want a reliable method of detecting the old install path and reusing it.
• Use the same install project to produce differently 'branded' versions of the same product. This happens often with my product line. We have a product that is almost identical as far as installation needs go. The only real differences are in the graphics, the product names, and perhaps a few components. It's valuable to work out a consistent and reliable method for being able to design the installer in such a way that you can fairly easily 'swap out' one brand for another without having to maintain two separate install projects.

If you have any other suggestions for common install tasks let me know. I hope to write up quick tutorials on each of these tasks.  

Over time, your company may come up with a few other tweaks and minor adjustments to the default installer project that you will want to routinely add to your project. This includes things like "Make all the dialog titles say the product name only and remove "InstallShield Wizard" from the title." or "Always create an MSI log when the install runs." As features like this become known -- do yourself a favor and write a quick little document that lists the feature, why it is wanted, and a quick list of what items to change in the installer in order to provide that feature. This gives you a quick template to follow whenever you start a new install project. And... should you ever win the lottery and run off to Bimini with your significant other , then the new install developer will thank you in his prayers for leaving that kind of documentation behind.

That's all for now!