cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
DLee65
Level 13

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:

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.
Labels (1)
0 Kudos
(4) Replies
ch_eng
Level 7

Dan,

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
0 Kudos
rguggisberg
Level 13

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.
0 Kudos
DLee65
Level 13

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.
0 Kudos
rguggisberg
Level 13

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.
0 Kudos