Launch File custom action command line error

[karlf]

Hello,

I am trying to launch a .bat file after my installation has finished. I have added it as a custom action, and I am trying to call a batch file (As administrator) and pass it the [APPDIR] as an argument in the command line field. When I pass the command line as just [APPDIR], the argument goes through, and because there are spaces in my path, since it's going to program files, the path fails when it gets to my .bat file (since it's an incomplete path). So, I added quotes around [APPDIR] and made it like this "[APPDIR]". But now, when I try to run it, I get an error saying, "There is a problem with this Windows Install package. A program ran as part of the setup did not finish as expected.". This only happens when I pass it with the quotes. I am testing this with a batch file designed to simply echo my argument passed to it.

When I pass it without quotes, I am able to see the first part of the path "C:\Program", however, if I try to add the quotes, my batch file will not even run or display anything, I just get the error.

What's interesting, because I am running it as admin, when the UAC control comes up, if I click on more details, I am able to see that the argument is being passed to my .bat file with the quotes around it, however, when it tries to run, I get the error.

Are there any ideas on what could be causing this issue?

Thanks

[Daniel]

Hello,

We have tested and reproduced the issue, it seems to be related to checking "Run as Administrator" option in your launch file custom action. A fix will be available in a future version of Advanced Installer, thank you for bringing it to our attention. As a workaround you could try to uncheck "Run as Administrator" in your custom action and set the whole package with Run as Administrator. This can be done in "Install Parameters" page.

Another workaround is to call the batch using another custom action type. For instance, you can call it from a "Launch Attached File" custom action type, using a VBS Script File. For example you could use the following code in the vbs file :

Code: Select all

const WindowStyleStealth  = &H20000000
set WSO = CreateObject("WScript.Shell")
WSO.Run "runas /user:administrator cmd.exe /c bat.bat Session.Property("APPDIR")", WindowsStyleStealth, true

This code runs the .bat file with administrator privileges and APPDIR property as an argument.

All the best,
Daniel

[karlf]

Thank you for the response. I have decided to go with the workaround provided, of just running the entire installation as administrator. That seems to work for now

[Daniel]

You're welcome.

All the best,
Daniel

[karlf]

Hello,

I am looking into the other workaround mentioned as well, I'm trying to find the best solution of my available options. I was wondering about the vbs script option. I tried to add that code and change bat.bat to the name of my script, however, I get an error message saying the script failed to run on install. I then changed the script to simply open a window saying "hello world", and that worked. I think that the vbs script provided is failing to find the location of my .bat file. I'm wondering, how to reference my .bat file so that the location of the file is picked up on and able to be executed? I simply have my .bat file in my Application Folder.

Thanks for the help

[Daniel]

Hello,

Please ignore the previous method I exposed because it could not work always as you need. Please try to use the following approach:

1. Create a new "Execute Inline Script Code" custom action with sequence and place it after "Finish Execution" action group in "Install Execution Stage"; the VBS custom action will launch the BAT file
2. Fill in the following VBS code :

Code: Select all

Set shell = CreateObject("WScript.Shell")
shell.CurrentDirectory = Session.Property("APPDIR") ' in this line you specify that the process current directory is APPDIR
shell.Run "bat.bat" & " " & Session.Property("FOLDER") ' this line launches bat.bat with command line parameter "FOLDER"

3. In order to run your BAT as an Administrator you need to append the following code to your BAT file:

Code: Select all

@echo off
CLS
ECHO.
:init
setlocal DisableDelayedExpansion
set cmdInvoke=1
set winSysFolder=System32
set "batchPath=%~0"
for %%k in (%0) do set batchName=%%~nk
set "vbsGetPrivileges=%temp%\OEgetPriv_%batchName%.vbs"
setlocal EnableDelayedExpansion

:checkPrivileges
 NET FILE 1>NUL 2>NUL
 if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges )

:getPrivileges
 if '%1'=='ELEV' (echo ELEV & shift /1 & goto gotPrivileges)
 ECHO.
 ECHO Set UAC = CreateObject^("Shell.Application"^) > "%vbsGetPrivileges%"
 ECHO args = "ELEV " >> "%vbsGetPrivileges%"
 ECHO For Each strArg in WScript.Arguments >> "%vbsGetPrivileges%"
 ECHO args = args ^& strArg ^& " "  >> "%vbsGetPrivileges%"
 ECHO Next >> "%vbsGetPrivileges%"

 if '%cmdInvoke%'=='1' goto InvokeCmd

 ECHO UAC.ShellExecute "!batchPath!", args, "", "runas", 1 >> "%vbsGetPrivileges%"
 goto ExecElevation

:InvokeCmd
 ECHO args = "/c """ + "!batchPath!" + """ " + args >> "%vbsGetPrivileges%"
 ECHO UAC.ShellExecute "%SystemRoot%\%winSysFolder%\cmd.exe", args, "", "runas", 1 >> "%vbsGetPrivileges%"

:ExecElevation
"%SystemRoot%\%winSysFolder%\WScript.exe" "%vbsGetPrivileges%" %*
exit /B

:gotPrivileges
setlocal & cd /d %~dp0
if '%1'=='ELEV' (del "%vbsGetPrivileges%" 1>nul 2>nul  &  shift /1)


REM ---PUT YOUR BATCH CODE HERE---- :

4. After this code sequence insert your BAT code, for example :

Code: Select all

@echo on
dir
@echo cd %1
cd %1
pause

In this way you will launch the .bat file as an Administrator. The "FOLDER" property is passed as a parameter to the BAT.

Please take a look on the sample project we attached to this post and let us know if this helped.

All the best,
Daniel

[karlf]

Hi Daniel,

Thanks for the pointers on what to do, it was a help. The solution you posted does indeed help, and it worked for me. For my last question related to this, I am wondering about the installation of drivers using the drivers page. I have done some research and contacted the support team and as I understand it, the drivers page does not support having a single .inf file for installing drivers that have both x86 and x64 architectures in it.

When I contacted AI support earlier, I was told to edit the .inf files that have been supplied to us, we are not the creators of the files. I was told:

"When editing the INF, place the lines with "x86" in their names in one 32-bit INF. Place the ones without "x86" or "x64" and those that specifically have "x64" in their names in another 64-bit INF"

I am a bit confused as to what makes something a 32 bit INF vs a 64 bit INF. Do I need to have a special naming convention? Is the framework smart enough to pick up on which architecture the INF is targeted towards without me having to do anything? I have tried this approach but it does not seem to be working for me. I simply end my installation on a error page saying the setup ended prematurely.

I have attached the 2 original inf files as well as the versions I have attempted to edit to make compatible with 64 bit systems (My edited ones are the ones with x64 at the end). These are attached as .txt files because the forum says .inf is an invalid file type to attach. I'm not sure if I am doing the edits correctly, but I don't see what other edits I could make either.

Thanks again for the detailed instructions on how to fix the problem from earlier.

[karlf]

Here is the last .inf file from above, since I'm not allowed to attach more than 3 files to 1 post

[Daniel]

Hello Karl,

I'm sorry but I cannot tell you for sure how you should successfully split your current mixed platform inf into two inf files: one for 32-bit platforms and another for 64-bit platforms.

However, as a workaround I suggest you to create two separate driver installers: one for the 32-bit driver and another for the 64-bit driver. Then you can create a main installation setup (a wrapper setup) containing the above 32 and 64-bit packages added as feature-based prerequisites. The main wrapper setup should be configured from "Product Details" page with the "Register product with Windows Installer" option UNCHECKED.

To create the 32-bit setup you can proceed like this:

1. go to "Files and Folders" page and add your driver files under "Application Folder" directory; each driver INF file should be added under a separate folder and also the driver resource file referenced by the INF should be placed relatively to the INF folder
2. go to "Drivers" page and add your drivers

To create the 64-bit setup you can proceed like this:

1. go to "Install Parameters" page and set the package type to a 64-bit package
2. go to "Files and Folders" page and add your driver resources in different folders under "Application Folder"; each driver resources should be placed under a separate folder
3. go to "Organization" page and check the "64-bit Component" flag for all of the installation components
4. go to "Drivers" page and add your drivers

When creating the wrapper setup project just add the above 32 and 64-bit setups as feature-based prerequisites configured to always install on 32, respectively 64-bit machines. Also, I've sent you by email a sample configured using the above settings.

Let me know if this helped.

All the best,
Daniel