When VBScript and JScript custom actions are even more evil than usual
As everyone knows, script custom actions are inherently evil. A security addition to Windows Installer 4.0 in Windows Vista means that script CAs are even more likely to fail; see Heath’s blog entry on the issue and Aaron’s follow-up.
But did you know that script CAs, evil that they are, nonetheless ship in Orca, MsiVal2, and even the WiX toolset? Shocking but true. The Internal Consistency Evaluators (ICEs) are implemented as custom actions in .cub files that are MSI databases with a vastly different schema you’re used to seeing. A couple of ICEs are written in VBScript so a misregistered VBScript engine will cause those ICEs to fail. As WiX v3 runs validation by default during linking (and on-demand using the Smoke tool), failed ICEs fail your setup build.
Of 98 ICEs in the version of Darice.cub in the Windows Vista SDK, only four are written in VBScript — yet that’s all it takes to fail your build.
If you run into the problem, check out the workaround Aaron offers before you take the drastic step of disabling validation.
Tags: best practices, custom actions
June 8th, 2007 at 07:51 #Aaron Stebner
Hey Bob - Do you know which 4 ICEs are written in VBScript? It would help knowing that when trying to narrow down this kind of ICE failure in the future.
June 8th, 2007 at 08:02 #Bob Arnson
Good point! In the version of darice.cub that comes with Orca from the Vista SDK, the ICEs that are implemented in VBScript are
ICE08
ICE09
ICE32
ICE61
I found this out by opening Orca’s darice.cub in Orca itself. The CustomAction table’s Source column points to rows in the Binary table. The other 94 ICEs are implemented in three type-1 CA DLLs.
June 11th, 2007 at 13:14 #Joy of Setup » Apple Safari setup built with WiX
[...] Software Updater package (instead of using a chainer). Already there’s a forum report of a 2738 error with the VBScript CA. And I guess the only way to report bugs is via forum posts…? It’s [...]
September 19th, 2007 at 08:55 #Edison M. Castro
I actually posted this to Aaron’s blog, but I am posting it here too
This is one the things that should have been taken care of by the instaler already. The instaler team has enhanced MSI for some while, but has not taken care of fixing some of the basic functionality of the product. I have submitted change request after change request for fixes to this since the beginning. Everytime I see posting referring to “this post by Rob Mensching”, I completly freak out.
This is total rubbish. All of his assumption are total bull. IMHO
1.- Robust code is difficult write in script.
This is utterly nonsense, bad code can be writing in any language, but specially C. If the developer of the custom action written in script can not do a simple try{}catch() on his code, changing to C would not make it any better.
2. Debugging script in the Windows Installer is difficult
Another stupid instaler team mistake and another request of mine. Has anyone on that team heard of “Active Scripting Host debug”. Microsoft for some while sold us the idea of scripting debugging, I built several of them. doesn’t that team care what their customer want?
3. Anti-virus products kill them
My anti-virus kills any new code I put in my machine. Many ways exist of fixing this, but the main one is: Just execute the stupid script, do not put it in the file system, get it directly from the binary table and execute it, simple isn’t it?
4.- Make sure jscript.dll and vbscript.dll are correctly registered.
So many things that are supposedly part of the base system (ie, media player, etc). Aren’t those part of the system too since they are required by and used by the former apps? Shouldn’t the system (MSI, etc) make sure they are in the correct state before executing an action which requires it?
This is just the tip of the iceberg. I honestly think that script should be the ONLY allowable way of writing custom action, since they provide sort of a sandbox model to protect the end user from ill-intented code from the part of the producer of the MSI and for the most part (i could say allways) they provide all the functionality you may possible need, besides the fact that script is so easy to write and debug (with the right support, of course)
I will send another set of emails to the Windows Installer Wishes mailto:msiwish@microsoft.com asking for some fixes for the upcoming 4.5 release. Let’s hope someone is actually listening…………
September 19th, 2007 at 14:48 #Bob Arnson
You use several “woulds/shoulds/coulds” in there. Today’s reality is that script CAs tend to cause more problems than native-code CAs because script has more dependencies (e.g., FSO, WMI). And I’d much rather the MSI team spend more time on native functionality so there’s less need to write CAs, rather than making them “easy to write.”
September 21st, 2007 at 02:18 #Peter Wone
Bob I can’t say I totally agree with you. It doesn’t matter how good the efforts of the MSI team, they will never meet everyone’s needs. Script, on the other hand, is a general solution.
I’ve built several setup kits that needed CAs to do odd things like rummage around inside an OLEDB database across a network, or probe on an IP address and port to see whether our discovery service is on the network, and if so ask it rather than the user for configuration info. This stuff would have been a walk in the park with script making use of C# assemblies. In C++ it was… educational. Which is similar to diabolical if you’ve never used C++ before.
Ed may have a slightly whiny tone but he also presents quite good answers to the major objections. In fact I am right now wondering whether it wouldn’t be interesting to write a CA that direct-hosts a VBScript engine that I keep inside the setupkit, rather than just throwing a VBS file at the shell and hoping it will run.
September 23rd, 2007 at 20:18 #Bob Arnson
Sorry, I’m not convinced. What you’ve described isn’t installation — it’s configuration. “Odd things” like that rarely belong in installation transactions; they’re best done before installation with a wrapper that passes data to the installer or with a configuration program that the installer kicks off afterward.
Even if MSI had bullet-proof support for script or managed-code CAs, it wouldn’t change the fact that if reliability is important, transactions should be as simple as possible. That’s true in databases as well as MSI.
April 1st, 2008 at 17:58 #Aaron Stebner's WebLog : How I resolved Windows Installer error code 2738 on Vista while running light.exe from WiX v3.0
[...] hive instead of or in addition to the HKEY_LOCAL_MACHINE hive. Also, as described in this blog post by Bob Arnson, four of the Windows Installer Internal Consistency Evaluators (ICEs) are implemented in [...]
May 5th, 2008 at 23:20 #Joy of Setup » VirtualBox 1.6.0 setup another example of the second law of thermodynamics
[...] It’s VBScript. Evil. One day after release, a user started a thread on the VirtualBox support forum about getting a 2738 error on Windows Vista. [...]