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."

Comments

• Anonymous
  May 20, 2004
  The comment has been removed
• Anonymous
  May 20, 2004
  The comment has been removed
• Anonymous
  May 20, 2004
  The comment has been removed
• Anonymous
  May 21, 2004
  The comment has been removed
• Anonymous
  May 21, 2004
  The comment has been removed
• Anonymous
  May 21, 2004
  This begs the question, is there really anything "better"? Executables can be (and have been) just as bad. In fact, they can be worse, because they don't suffer the limitations of the scripting environment.
  
  I can't wait to see your future blogs on CustomActions. Should be a eye-opener. :)
  
  Keep up the good work.
• Anonymous
  May 21, 2004
  Rob,
  
  Being hardcode about solid setup programs is good.
  
  As one who has had to create some pretty elaborate custom actions (even a few I wrote), I have come to the conlusion that custom actions should be avoided at all costs. (a third axiom of setup?)
  
  I have been gradually eliminating custom actions from our installers and find that they have generally been required:
  
  1. To make our install 'just like it used to be' (pre-MSI)
  2. To cover for poor application design.
  3. To cover for poor MSI package design.
  
  None of these are really compelling requirements....
  
  Thanks for WiX, I hope to be able to incorporate it in our build in the future. We have been in the 'text only' input camp since 1999, but with a homegrown tool set that is pretty well imbedded now.
• Anonymous
  May 26, 2004
  The comment has been removed
• Anonymous
  June 03, 2004
  I'm more than happy to stop using JScript. Where's my C# CA support?
• Anonymous
  June 09, 2004
  The comment has been removed
• Anonymous
  June 10, 2004
  The comment has been removed
• Anonymous
  June 27, 2004
  The comment has been removed
• Anonymous
  October 27, 2005
  Rob, I know you'll pull your hair out for suggesting this, but I need to ask you a question.
  
  How come there are MSI Custom Action types only support VBScript and JScript? Would it have been possible in MSI to define a generic CA Type # that meant a script and then place a script language tag in either an additional column or embedded within the script itself?
  
  
• Anonymous
  November 19, 2005
  > That's all fine and good, but what
  > about the people that have come
  > from a script based langauge, like
  > InstallShield, and do not have the
  > developer's know how in other
  > languages like C++, C# ...?
  
  Seriously, learn how to program.
  Learn C#. Or something.
  
  Anyhow, I seriously think MS dropped the ball with the installer designer in VS.NET 2003/5 . And yeah, while WiX is ULTRA cool, I am STILL waiting for C# Custom Action & Greek Language support in the Installer desinger/packager.
• Anonymous
  May 08, 2006
  The comment has been removed
• Anonymous
  July 11, 2006
  I'm late to this too, but to answer John, the major install authoring tools (certainly Wise and AFAIK InstallShield) both allow you to specify file & reg entries to be removed at uninstall time.
  
  As for script in CAs, it is sometimes necessary to work around limitations/bugs in the authoring tools. I had INCREDIBLE problems with Wise's creation of virtual directories, where an MSI would create the VD but stopped creating the accompanying application. No amount of re-editing would fix it. In the end, with deadlines approaching, the quickest route was to shoehorn CreateVDirs.VBS from the Platform SDK into use. It would have taken F O R E V E R to get the same functionality authored in a DLL or EXE, what with code review, testing, QA, etc, etc.
• Anonymous
  July 12, 2006
  Imagine a blog entry where Bob Arnson steps in and tells the tale of the Office PIAs for the Creative Commons Add-in for Microsoft Office.