E
Eleanor
rather than using
WScript.CreateObject("WScript.Shell")
use
CreateObject("WScript.Shell").
I have been googling the web/newsgroups on an error I am having to no
success. It seems that a VBScript that works fine outside of MSI VBScript
custom action would work fine, but fail in the MSI with strange
errors/problems:
Error 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor. Custom action FixXLSReg script
error -2146828283, : Line 165, Column 4,
MSI (s) (FC:6C): Product: CallCSH -- Error 1720. There is a problem with
this Windows Installer package. A script required for this install to
complete could not be run. Contact your support personnel or package vendor.
Custom action FixXLSReg script err
or -2146828283, Microsoft VBScript runtime error: Invalid procedure call or
argument: 'arVNames.EnumValues' Line 165, Column 4,
When I run the script through debugger (via Wise/Visual Studio for script
debugging), I get weird problems. For example, in the function
getOpenSequencesFromReg, I can not iterate through objReg's objReg.Methods_.
I have tried to make the objReg global. Then I could iterate through the
methods. Even though when I iterate through the methods, I could see
"EnumValues" method, the script still generate the invalid procedure call or
argument error. But this seems to be working perfectly fine when executed
through CScript outside of MSI.
I have tried putting the VBScript in Immediate Execution, or Deferred
Execution, and in various positions; using elevated privs; playing with the
GetObject line. Nothing works. Only time I got it to work is by calling
CScript.exe to execute the script directly. So, I am assuming it is not a
security priviledge issue since the script executed properly via CScript.
The only conclusion that I could draw is that in MSI, the scripts are
executed using a different script engine/method? Any similar problems that
I have seen in the newsgroup seems to have the same solution/workaround of
"rewrite the custom action in a DLL, and call the DLL". Any other
ideas/fixes?
WScript.CreateObject("WScript.Shell")
use
CreateObject("WScript.Shell").
I have been googling the web/newsgroups on an error I am having to no
success. It seems that a VBScript that works fine outside of MSI VBScript
custom action would work fine, but fail in the MSI with strange
errors/problems:
Error 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor. Custom action FixXLSReg script
error -2146828283, : Line 165, Column 4,
MSI (s) (FC:6C): Product: CallCSH -- Error 1720. There is a problem with
this Windows Installer package. A script required for this install to
complete could not be run. Contact your support personnel or package vendor.
Custom action FixXLSReg script err
or -2146828283, Microsoft VBScript runtime error: Invalid procedure call or
argument: 'arVNames.EnumValues' Line 165, Column 4,
When I run the script through debugger (via Wise/Visual Studio for script
debugging), I get weird problems. For example, in the function
getOpenSequencesFromReg, I can not iterate through objReg's objReg.Methods_.
I have tried to make the objReg global. Then I could iterate through the
methods. Even though when I iterate through the methods, I could see
"EnumValues" method, the script still generate the invalid procedure call or
argument error. But this seems to be working perfectly fine when executed
through CScript outside of MSI.
I have tried putting the VBScript in Immediate Execution, or Deferred
Execution, and in various positions; using elevated privs; playing with the
GetObject line. Nothing works. Only time I got it to work is by calling
CScript.exe to execute the script directly. So, I am assuming it is not a
security priviledge issue since the script executed properly via CScript.
The only conclusion that I could draw is that in MSI, the scripts are
executed using a different script engine/method? Any similar problems that
I have seen in the newsgroup seems to have the same solution/workaround of
"rewrite the custom action in a DLL, and call the DLL". Any other
ideas/fixes?