VBScript (and Jscript) MSI CustomActions suck.
Today was one of those days where you finally get around to looking at the time and wonder where the heck the hours went. It wasn't even like I really got a lot done. I think my context switch costs have been really high lately. It feels good to finally be home chilling out to the Perfecto Chills albums. I thought I'd relate a short story to you why VBScript (and Jscript for that matter) should not be used for CustomActions in an MSI.
Today, I realized it was 15:39 when a fellow developer, we'll call him Joe, called me at work. My first thought was, "Jeez, it's almost 4 o'clock and I haven't got anything done!" My second thought was, "I bet Joe is screwed." Joe only calls me when the WiX toolset has completely failed or he has hit the wall with the Windows Installer. Today, Joe had hit the wall.
"Rob, have you been tracking the email thread about the CustomAction of mine that is failing?" I had seen this thread earlier in the day and remembered Joe mentioning something about a VBScript CustomAction. "A little bit, you're not really using VBScript for your CustomAction, are you?"
That was it. Joe was attempting to debug some rather complex issues with a VBScript CustomAction interacting with some COM components during an install. Everything seemed to work fine if he ran the VBScript (slightly modified) in the cscript.exe or wscript.exe hosts. However, when the script executed in the Windows Installers ActiveScript engine it failed in rather mysterious ways.
Interestingly enough, a Windows Installer developer attached one of the many emails that I send to people when they are having problems using VBScript for CustomActions. In those emails, I always suggest that script never be used for CustomActions in MSI. So, Joe called me and asked, "So what can I do, Rob?"
My answer was simple, "Joe, there is a reason I recommend never using VBScript for CustomActions. It's because there isn't really a whole lot you can do when you get into this kind of situation." Then I provided him a few ideas that started with attempting to get the script debugger to somehow attach and try to then debug over to the COM component and ended up suggesting getting the command-line debugger attached to the COM component on load. None of which is trivial.
What I don't understand is why people completely disregard dire warnings that certain technologies should not be used in certain circumstances. Yes, I understand it is extremely easy to write CustomActions in VBScript. No, that doesn't make it a good thing to use in your install.
So, I'm blogging here tonight at the end of a very long day to share with you three reasons, I recommend you not use VBScript or Jscript for CustomActions:
1. Robust code is difficult write in script. Setup code must operate on machines that are in an unknown state. In such hostile environments, there are many different ways that code can fail. Properly recovering from error conditions is very important (even if it just results in rollback). "On Error Resume Next" is not conducive to proper error handling in code. For this reason alone, Microsoft Office banned all script CustomActions from their MSI files. I am admittedly biased but I believe Office has one of the most impressive, smooth, and stable setup programs for the Windows platform, especially considering its complexity.
2. Debugging script in the Windows Installer is difficult. Some might even argue it is impossible to debug script CustomActions. As Joe is going to find out for the next few days, debugging the interactions between the Windows Installer, the scripting engine, and any other objects is a non-trivial task because the tools are so primitive. There are many tools for C/C++ code that can have very low impact on the machine if you are tracking a particularly skittish bug. Maybe I'm only called in when bugs are really hard, but there have been many times I was thankful for ntsd and pageheap.exe.
3. Anti-virus products kill them. This one just killed me. A couple years after Office banned the use of scripting for CustomActions, Visual Studio shipped their first MSI setup. They decided it would be okay if there were a few script CustomActions. When customers got the product, PSS started getting reports of the Visual Studio setup mysteriously failing and rollingback. After some very long calls, PSS discovered that if the users' anti-virus programs were disabled the installations would succeed. Turns out many of the top name anti-virus programs considered the scripts hosted by the Windows Installer to be virus and would kill the scripts off failing the Visual Studio install.
Anyway, hope you enjoyed the stories and remember, "VBScript and Jscript suck for CustomActions."
Copyright © Rob Mensching