Hi,

I have an MSI that installs files, then I'm trying to execute one of the exe file with parameters using a VBScript Custom Action.
First I use a Set Property to define INSTALLDIR.
The CA is set in the sequence after ScheduleReboot
The property name is set with the name of the Custom Action I'm using to run my exe

Here's the script stored in that Custom Action :


On error resume next
Dim oShell
'sDir returns INSTALLDIR
sDir = Session.Property("CustomActionData")
strCmd = "myExecutable.exe"
sParam="-myParam1 -myParam2 -myParam3"
sCom=(chr(34) & sDir & strCmd & chr(34)) & " " & sParam
Set oShell = WScript.CreateObject ("WScript.Shell")
'Show me the the value returned by sCom
MsgBox sCom
oShell.Run sCom, 6, True
Set oShell = Nothing


The CA is set in the sequence after the Set Property CA with a Deferred Execution in System Context
The value returned by by the MsgBox is exactly the command line I want to execute ("C:\Program Files\myAppFolder\myExecutable.exe" -myParam1 -myParam2 -myParam3) but unfortunatly nothing happens.
The Code works perfectly outside the msi (if you consider sDir with a full given name path)
This is really giving me a hard time to try and make it work..
after lots of different tests, in despare I turn to you guys... any help would be really appreciated
Thanks in advance.

It is quite difficult to find a bug in ones code when you look for it. It's even harder when you're convinced your code is right.

Alan
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Set oShell = WScript.CreateObject ("WScript.Shell")

depending on how you put the script in your package, you might want to try omitting the WScript. part. So that becomesSet oShell = CreateObject ("WScript.Shell")
Answered 05/17/2010 by: pjgeutjens
Red Belt

Please log in to comment
0
To explain Pieter's response, the 'WScript' directive is only relevant to the Windows Scripting Host (WScript.EXE and CScript.EXE). The Windows Installer engine uses its own (let's call it) interpreter which doesn't know that directive and will return 172x errors in your embedded Custom Actions. CAs which call out explicitly to WScript/CScript will work OK. However, it's good practise for a packager to drop it, since you can test scripts externally and then import them into your MSI without change. Lastly, note that this applies ONLY to the WSH directive. Objects which use the word 'WScript' as part of their ID (e.g. WScript.Network) will need to retain that prefix.
Answered 05/17/2010 by: VBScab
Red Belt

Please log in to comment
0
Thanks a lot to you both, and for the solution (which works fine ! ) and for the great explanation. I did not have that notion.
Thanks again ! [:)]
Answered 05/18/2010 by: alansch64
Orange Belt

Please log in to comment
Answer this question or Comment on this question for clarity