/build/static/layout/Breadcrumb_cap_w.png

Passing Variables?

Ok, i'm trying to install a service pack for an application called FRx. The main installation is simple...an InstallShield, create a .iss file, etc. No problems...

The SP is a different story of course. For some odd reason, it wants to default to C:\ program files for the program folder (where the main installer installs everything in C:\Program Files\FRx Software). If it wasn't for this oddity, I could just throw a /s after it and be done with it.

Looking through the log file, it looks like it calls an MSI that I can't find anywhere. Either way, there's a massive list of properties at the end, and I see the one I want to call (SOURCEDIR) and change. However, no combination of command line switches seems to change this propery or even pass it into the install. It takes /s and nothing else (though it does look like there's some sort of -p command in it, but I can't figure out for the life of me how to work it....documentation would be lovely...lol).

Anyone have any ideas? It would save one of our techs from having to foot it around to each PC to do this...


** - one side-note. this installation is a WISE installer, not installshield. i've tried installing with: /S /M=c:\install.txt with properties i've found in the log file, but so far it still keeps looking for some file in the program files folder root

0 Comments   [ + ] Show comments

Answers (7)

Posted by: MSIPackager 15 years ago
3rd Degree Black Belt
0
Yeah - capture it.
Posted by: RichC 15 years ago
Senior Yellow Belt
0
I was trying to avoid doing that just for a patch...the main app install works just fine.
Posted by: anonymous_9363 15 years ago
Red Belt
0
*Some* IS setup stubs understand the /V switch which enables one to pass arguments to what is eventually an MSIExec command line, thus you could try:

.......setup /V"SOME_PROPERTY=whatever"

or something like that. I can't recall the details with quote/speech marks so maybe Google for 'SETUP.EXE +"/V"'
Posted by: RichC 15 years ago
Senior Yellow Belt
0
I believe it's something like setup.exe /s /v"/qn variable=value" i've tried those as well. this one just looks to be put together badly...repackaging may be my only hope, but i never seem to have much luck with packaging a patch/service pack.
Posted by: anonymous_9363 15 years ago
Red Belt
0
If you typed it exactly like you show in the above, that may be the cause. Pubic properties need to be expressed in all upper-case, otherwise they are ignored. Thus, your example should be: setup.exe /s /v"/qn VARIABLE=value"
Posted by: RichC 15 years ago
Senior Yellow Belt
0
that was just a mistype on my part

just to be safe though, i went back and did all the public variables/properties I could find that referenced the true install directory from a successful install log (done manually) and placed them in a command line. still no luck. basically, this patch install sucks [;)] not feeling confident about a repackage either...
Posted by: nheim 15 years ago
10th Degree Black Belt
0
Hi Rich,
Looking through the log file, it looks like it calls an MSI that I can't find anywhere.

The logic to determine the directory of the installed SW seems to have its weak sides...
Are you sure, the SP has an MSI inside?
If yes, the MSI in the log would point to a temporary location.
But this could be a patch, which comes as MSP file.
Then you would see the log pointing to the installed MSI in the %windir%\installer directory.
If this is the case, the MSP is most likely copied to the temp folder and executed from there.

Regards, Nick
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ