Share via

Don't use vbscript/jscript to write your custom actions!

  • Article

Rob Mensching wrote a blog entry a while back that explains some reasons why you should not use script-based custom actions in your setup. I encourage you all to read it if you haven't yet, and I also strongly encourage you to heed his recommendations if at all possible.

I can personally relate to one of his explanations as well. Reason #3 on his list talks about anti-virus programs. When we shipped Visual Studio .NET 2002 we started getting reports of seemingly random failures during setup from our product support team. After some detailed analysis we found that many of these failures were being caused by overly aggressive anti-virus programs that were blocking scripts from running even as part of custom actions during VS setup. We scrubbed our custom actions before shipping Visual Studio .NET 2003 to re-write or eliminate the script-based custom actions to avoid these failures, and we were able to eliminate a fairly high support call generator.

Comments

  • Anonymous
    February 08, 2005
    Hi Aaron, I actually published a rebuttal to Rob's post a while ago (link below). Statements saying "don't" and "never" regarding the use of a language or platform capability are almost always a bit overreaching.

    This sort of reminds me of the C/C++ "goto" debates...

    In any case, my rebuttal can be found here:
    http://bonemanblog.blogspot.com/2004/06/vbscript-and-jscript-msi-custom.html

  • Anonymous
    February 08, 2005
    The comment has been removed

  • Anonymous
    February 08, 2005
    I am changing the topic a bit, but I'd like to extend on a point Steve made in his blog regarding using &quot;MSI Standards&quot;. I would go further and say: &quot;Always try to stay with MSI Standard actions and avoid CAs when possible.&quot;<br><br>What I've noticed with my interactions with countless setup developers is that CA's are way over used. CA's are often used because the setup developers are not familiar with the Windows Installer technology and the perception among developers are that it's easy to just write some code to solve setup issues. As any experience setup developer will tell you, most setup failures are due to poorly written CAs and not standard Windows Installer actions. Using native Windows Installer functionalities generally will take care of issues such as ref-count, uninstall, rollback, and many other pitfalls that can create major setup issues. Just remember that a setup failure is mostly likely worst than any bug you can come up with in your software, so put some effort into making a robust setup and stick with standard actions.<br>

  • Anonymous
    February 21, 2005
    If Script Actions are a "Never Use" feature then why was support for Scripting host added to the MSI installer in the first place.

    Are you really stating that Script Custom Actions a feature that should be deprecated in MSI?

  • Anonymous
    February 21, 2005
    My personal opinion is that script-based custom actions should not be used, but I am just one person. If I was writing my own setup I would choose to use DLL-based custom actions if I had to use custom actions at all.

    As Steven points out in his blog there are ways to make script-based custom actions reasonably robust, which eliminates some of my concern. I simply haven't seen enough of that discipline in place on the groups I've worked with who use script-based custom actions. Instead they tend to choose script because it is quicker and easier to get something going. They always intend to rewrite their custom actions as DLLs in the future when they have more time but in reality that always ends up at the bottom of the to-do list and the work gets cut.

  • Anonymous
    February 26, 2005
    Hi Aaron! Since there is a rule at Microsoft regarding DLL based CA's, and I'm sure you use COM in some of them, and given Larry Osterman's post at http://weblogs.asp.net/larryosterman/archive/2004/05/12/130541.aspx

    How does the MSI engine handle CA DLL's in this regard? Are the DLL's run in their own thread (thus making it safe to CoInitialize in it)? Should we spin off a worker thread in the DLL if we need to use COM as Larry suggests? What do your CA's look like in this regard? The documentation is a bit fuzzy in this area, and a trial and error approach may rely on an assumption that is subject to change, ala the Pragmatic Programmer's "Programming by Coincidence" topic.

    Perhaps this could be the subject of another blog topic rather than a simple (but probably not so simple) reply here...

  • Anonymous
    February 27, 2005
    Steven,
    I don't know about the MSI engine, but I can speak to my comment a bit. There is a key caveat in the comment: It depends on the threading model of the caller - if the caller's already called CoInitialize, then you're ok calling CoCreateInstance in your DLL. My comment was for the generic case - if you're writing a DLL that's going to be used by different clients, you can make no assumptions about the client.

    But a CA isn't a general purpose DLL, instead it runs under a single application, msiexec. So the restrictions that apply to generic DLLs don't necessarily apply to CAs

  • Anonymous
    February 27, 2005
    The comment has been removed

  • Anonymous
    March 01, 2005
    Hey Steve, sorry for the delay on this. This question rang a bell so I dug into some of the emails that have gone across our internal Windows Installer question-n-answer alias and here is the official answer from the Windows Installer team:

    "One of the first things that a custom action server does when it is created is to call CoInitializeEx(0, COINIT_MULTITHREADED).

    However, the thread on which a DLL custom action is run is different from the main thread (on which COM is initialized) and COM will not be initialized on it. It is up to the custom action to initialize COM to its liking."

  • Anonymous
    March 02, 2005
    That is fantastic, Aaron - I take it that every Custom Action DLL call is done on a different thread than the main (and a different thread from the "Custom Action Server". From a terminology standpoint, I am not sure what a "Custom Action Server" actually is (other than seeing the PID of it in the logs when it is spun up - one seems to be created impersonated and one elevated based on install context of immediate vs. deferred/rollback). My guess is that the "Custom Action Server" is the plumbing that contains the code that glues calls made using HINSTALL to the actual MSI engine. I wish some of these interesting tidbits made it into MSDN, though.

  • Anonymous
    March 02, 2005
    Hey Steve - these are really good questions. I went ahead and posted a new entry on my main blog page with some more info about custom actions and how they are managed by Windows Installer (I wanted to put it on my main page to make it more discoverable to others as well).

    You can find this new post at http://blogs.msdn.com/astebner/archive/2005/03/02/384088.aspx, please let me know if you find it useful or not and/or if you have any follow up questions....

  • Anonymous
    March 02, 2006
    The comment has been removed

  • Anonymous
    March 24, 2009
    I agree with Christopher.  I've seen Custom Actions with regasm.exe in them when MSI provides for registering assemblies, no need for a CA to do that.  

  • Anonymous
    March 24, 2009
    Hi Aogilmor - I'm with you on this.  There is no reason to need to use a custom action to accomplish something that can be done with Windows Installer standard actions.  You can use tools like Tallow (in WiX v2.0) or Heat (in WiX v3.0) to harvest registration information from DLLs in order to eliminate the need for self-registration or regasm.exe custom actions in an MSI.