What not to do when creating an MSI-based setup

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.

Comments

• Anonymous
  September 11, 2006
  You hit it on the nail Aaron.  Fortunatly MSI has really good Transformation support so it's possible to patch the MSI and get around the bad design.
• Anonymous
  September 12, 2006
  Hi Christopher - It is true that you could work around this by creating a transform, but I generally do not recommend using transforms to modify shipping products like that.  If you do that, you run the risk of transforming it too much and preventing future hotfixes or service packs from being able to apply correctly on systems that have the transformed product installed.
  
• Anonymous
  September 13, 2006
  I would respectfully disagree.  I worked in Production Engineering managing the application integration, packaging and deployment to over 18,000 SMS clients.   If the original vendor could get the setup right ( very few do unfortunatly ) then you can do your integration testing and go straight to deployment.
  
  But when a vendor fails to get it right you have to either transform or repackage it.  It's a controlled environment that you own so you can safely make these baseline changes since your responsible for regression testing and integration testing the patches and upgrades that apply to the product later on in time.  Basically you own it from that point on.
  
  If the vendor won't fix his problems, it's impractical to not fix the problems yourself because of the sheer number of machines involved in deployment.   When dealing with thousands of machines, any where south of 99.9% reliability involves alot of manual labor to fix broken installations.
  
• Anonymous
  September 13, 2006
  Hi Christopher - Your scenario is the exception to the rule.  I say that I "generally" don't recommend modifying shipping products with transforms because most people who try to do this don't have the level of control over the installation/deployment environment or the knowledge of the ramifications of doing so.  In some cases, it probably makes sense to modify a badly authored setup to avoid the types of issues that I described in my blog post, as long as you realize that you might have to re-deploy the whole product instead of just a patch if there is a hotfix for that product released in the future.