cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Ron_Schaeffer
Level 6

Detect if VBScript / Scripting Host is enabled?

We use VBScript in Basic MSI installers. Occasionally we will encounter customer sites where the scripting host is not enabled. Sometimes the result is relatively beneign (e.g., using VBScript for some dialog validation), and sometimes it can be catastrophic (e.g., registry values partially calculated via VBScript are not correctly set).

Is there some way of detecting whether or not the scripting host is installed / active / enabled? If there is then I'm thinking I can use that as a Launch Condition for my installer and not even run if VBScript is not executable.

Thanks.
Labels (1)
0 Kudos

(3) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

I don't think there's likely to be a real sign of this. Sometimes it's an anti-virus system which blocks VBS, sometimes it's other problems. However if it consistently does or does not block VBS execution on a given machine, why not set a simple condition based on a simple property that a VB custom action should set. If the action can't run, it won't set the property, and your condition can trigger a clean abort.
0 Kudos
cbragg
Level 7

I'm with Michael on this one too.

Create a vbscript custom action to run early on with:

Session.Property("VBSCRIPTWORKING")

Don't forget to ignore exit code on your custom action

Then immediately follow with an error type custom action with it's condition set to Not VBSCRIPTWORKING.

By using an error custom action, your installer will abort and you'll get some decent logging
0 Kudos
Ron_Schaeffer
Level 6

Thank you both. Sometimes we get so wrapped up in anticipating an "elegant" or "elaborate" solution that we ignore the simple or obvious. [In this case I'm using a royal "we" so that I don't feel like such a schmuck 🙂 ].

I have created a VBScript custom action which simply sets a property:

[FONT="Courier New"]Property("ISVBSCRIPTWORKING") = "True"[/FONT]

This CA is then sequenced prior to LaunchCondition, and I introduced a Launch Condition on ISVBSCRIPTWORKING.

So far I haven't been able to prove this revision corrects the issue - because I don't have access to the system on which this issue occurred. However, I have proved that it doesn't break my install in the normal course of events 🙂 .

As a side note, if VBScript.dll is not registered (which we have seen happen once in a while, but which was not the reason behind this post), Windows Installer itself will throw an error and terminate, "Error 2738. Could not access VBScript run time for custom action .", and we never get to the launch condition.
0 Kudos