This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Basic MSI: InstallScript custom action
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 13, 2013
11:23 AM
Basic MSI: InstallScript custom action
I have a basic msi project in which I have an InstallScript custom action.
The custom action runs LaunchApplication and sets the working directory to INSTALLDIR
Now, I know that the paths are set correctly, because the actual batch file executes. So INSTALLDIR must be set correctly because I use that to obtain the path to the batch files.
However, unless the working directory is set properly, the batch files will always fail, because the batch files are written with only the names of idividual files inside of them, and CMD.exe tends to execute in the system32 context without the working directory set properly.
I have been at this for many days working on variations of this problem.
First I started by calling CMD.exe directly and passing in /C "batchfile.bat". This process fails. Note that in each of these tests, the working directory for LaunchApplication is set to "INSTALLDIR", not the property name as I have it spelled out here, but the value of INSTALLDIR as received by MsiGetProperty inside of my InstallScript custom action. I just wanted to be clear here because some people read these things literally 🙂
I have tried adding quotes to the working directory using the following:
My command line is formatted as follows:
When I ran this with the CMD prompt and the /K option, the context was showing CMD window was set to system32, not my strWorkingDir value. The MSI log definately shows that strINSTALLDIR is set correctly.
What am I missing in this puzzle?
Thanks.
The custom action runs LaunchApplication and sets the working directory to INSTALLDIR
Now, I know that the paths are set correctly, because the actual batch file executes. So INSTALLDIR must be set correctly because I use that to obtain the path to the batch files.
However, unless the working directory is set properly, the batch files will always fail, because the batch files are written with only the names of idividual files inside of them, and CMD.exe tends to execute in the system32 context without the working directory set properly.
I have been at this for many days working on variations of this problem.
First I started by calling CMD.exe directly and passing in /C "
I have tried adding quotes to the working directory using the following:
strINSTALLDIR = sInstallDir;
strWorkingDir = sInstallDir;
LongPathToQuote(strINSTALLDIR, TRUE);
LongPathToQuote(strWorkingDir, TRUE);
My command line is formatted as follows:
sFullPath = sInstallDir ^ sFile;
LongPathToQuote(sFullPath, TRUE);
nCmdResult = LaunchApplication(sFullPath, "",strWorkingDir, SW_NORMAL, 120000, LAAW_OPTION_WAIT);
When I ran this with the CMD prompt and the /K option, the context was showing CMD window was set to system32, not my strWorkingDir value. The MSI log definately shows that strINSTALLDIR is set correctly.
What am I missing in this puzzle?
Thanks.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 16, 2013
03:00 PM
Dan,
I haven't used the szDirectory parameter with LaunchApplication before, but perhaps you could use something like this in your batch file instead?
HTH
I haven't used the szDirectory parameter with LaunchApplication before, but perhaps you could use something like this in your batch file instead?
@echo off
@echo current working directory:
@echo %cd%
@echo directory where this batch file is located:
@echo %~dp0%
@echo changing working directory to this batch file directory
cd /D %~dp0%
@echo current working directory:
@echo %cd%
HTH
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 16, 2013
03:17 PM
Dan,
I think HTH has the right idea. You will probably find that your current directory is not what you think it is. By way of explanation... if you are executing via 'Run as Administrator' the current directory will typically get changed to "C:\Windows\System32". That is why I put the following line near the beginning of all my bat files:
PUSHD %~dp0
That will put the current directory back to what you expect. You need to do that before you access any files/folders in the bat file.
If that doesn't do it for you... are you targeting 32 or 64 bit? Because there are 2 CMD.exe's.
I think HTH has the right idea. You will probably find that your current directory is not what you think it is. By way of explanation... if you are executing via 'Run as Administrator' the current directory will typically get changed to "C:\Windows\System32". That is why I put the following line near the beginning of all my bat files:
PUSHD %~dp0
That will put the current directory back to what you expect. You need to do that before you access any files/folders in the bat file.
If that doesn't do it for you... are you targeting 32 or 64 bit? Because there are 2 CMD.exe's.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 17, 2013
12:22 PM
You guys are correct. I have used PUSHD and POPD numerous times in my build scripts but this application had never occurred to me in this context. Once I read your comments I was like Why in the world did I not even think about that. It had never even occurred to me to modify my batch files. 😄
That is the value of a fresh perspective. Thank you so much.
Also, I agree that the 'Working Directory' for some reason is not being set properly in this context. I know the value being supplied is correct, but the way it is handled by the command window is not correct.
That is the value of a fresh perspective. Thank you so much.
Also, I agree that the 'Working Directory' for some reason is not being set properly in this context. I know the value being supplied is correct, but the way it is handled by the command window is not correct.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Dec 17, 2013
04:58 PM
That's just the way it works with 'Run as administrator'. I guess they don't want you impersonating another user. It is easy to prove. Just open a CMD window and echo %CD% if your prompt does not already show the current directory. Then open another CMD window via 'Run as administrator' and you will see the difference.
