Can the path variables such as %ModulePath% be used in the command line field of custom 3rd party packages? Is there a better way to pass an included file path to the installer?
I've answered my own question: %ModulePath% is not evaluated when used as a command line parameter, but you can use the environment variable %cd% instead.
Yes, %modulepath% is a value internal to PackageBoot, but an interesting discovery about using %cd%!
Unfortunately %cd% didn't work for my situation since I was trying to pass the current path to msiexec as part of a public property. It seems that the variable isn't parsed before being passed and msiexec.exe doesn't evaluate it either, so I'm looking for another alternative.
Hmmm.. that makes sense. It's an environment variable evaluated by the shell. If the execution is not occuring within the context of the shell, there's no way to evaluate it.
For scripts it should be functional, if it's executing within the context of a cmd.exe session.
Another suggestion just offered as a result of a internal conversation... if you're not using PackageBoot for this project, it might be helpful to do so.
At a minimum it will give you access to the %modulepath% environment variable which can then be used within the context of a <program> element.
I am trying to install an MSI that accepts the path to a license file as a public property. Is there some area within package boot editor where I can specify an environment variable (either %modulepath% or %cd%) as part of a command line parameter and have it evaluated before being passed to msiexec?
I have tried using package boot to edit the command-line of the main MSI installation, but this seems to have the same effect as editing the command line directly in the wizard without using the package boot editor - namely, the variable name is passed to msiexec rather than the value.
When defining Command-line parameters in a "Run a Program" task in PackageBoot, the %MODULEPATH% variable IS available. The associated license file would need to be included in the "Additional Files" list so that it's contained within the CAB file downloaded by the client, and thus unpacked into the installation source folder.
For a functional example of how this is done, see the Adobe Air v3.8 package that was published last week. %MODULEPATH% is evaluated by PackageBoot.exe prior to spawning the CMD.EXE to execute this process, so the CMD.EXE gets a fully qualified (local) pathname to the make_mod.cmd script contained in Additional Files.
From that package:
<preexecution>
<programs>
<program failureaction="stop" enabled="true" name="cmd.exe" type="exe" typeaction="runandwait" pathtype="simplepath" path="%windir%\system32" successcode="0">/c %MODULEPATH%\make_mod.cmd</program>
</programs>
</preexecution>
<postexecution>
</postexecution>
That's great information, thanks! But, why doesn't this seem to work with an MSI installation with packageboot enabled? How is that different from the "Run a program" task with the program type set to "Install MSI"?
Does this only work with exe-type programs? Is this just a temporary environment variable set by packageboot and then evaluated by the command processor? I tested and confirmed that the %modulepath% variable is evaluated when packageboot executes the command line for an exe-type program task, but it doesn't seem to work when I specify an msi installer. At least, the msi log shows that the variable name was passed on the command line rather than the value.
I'd need to see exactly what you're doing, Andrew, in order to answer that question. If you want to export the package and email me the CAB I'd be happy to take a look.
