What not to do when creating an MSI-based setup

  • Article

A couple of days ago, I described a setup failure that I ran into and outlined how I approached solving it. While investigating that issue, I found a couple of problems with the design of the setup package that I was trying to help the customer install. I wanted to describe these problems and try to encourage anyone reading this to not do these things when developing your own installers.

To provide a bit of background, the customer could not install the Enterprise Instrumentation Framework package because of a custom action failure for the action named IsDotNetInstalled.

Issue #1: Jscript-based custom actions

While investigating the original installation failure, I found that several custom actions in the Enterprise Instrumentation Framework setup package are implemented using JScript. There are multiple reasons why this is a bad thing to do. To paraphrase this post by Rob Mensching:

  1. Many anti-virus programs have script blocking functions that can cause setups with script custom actions to fail and roll back 
  2. Writing robust code in a scripting language is difficult to write
  3. Debugging script that is running in the context of a Windows Installer-based setup is difficult

Issue #2: Implementing a custom action to do something a standard action can do

Because the IsDotNetInstalled custom action in the Enterprise Instrumentation Framework setup package is script-based, I was able to extract it from the MSI using steps described here and examine it in more detail.

When I did that, I found that the IsDotNetInstalled function in the custom action script queries registry values to determine whether or not the .NET Framework 1.0 and 1.1 are installed on the user's system. This type of prerequisite checking can be accomplished with standard actions in Windows Installer - namely the AppSearch and RegLocator tables.

Summary

I want to point out the above issues because of this one overarching fact - if the above 2 issues had not existed in the Enterprise Instrumentation Framework setup package, the customer would have been able to install this product without needing to contact me for assistance despite the fact that one of the Windows script DLLs was not registered correctly on their system. This setup failure was therefore totally avoidable had the setup been developed with some Windows Installer best practices in mind.