Showing results for 
Show  only  | Search instead for 
Did you mean: 
Level 4

Multiple releases in multiple INSTALLDIR

Is it possible to create a single ISM project which contains multiple releases each of which has a different default installation directory value (INSTALLDIR)?
Labels (1)
0 Kudos
3 Replies
Level 7

why don't you set your INSTALLDIR depending on conditions? use a "Set Directory" custom action.
0 Kudos
Level 4

Okay, I can see that works. Thank you.

What if I wanted to change my license aggreement RTF file depending on my product configuration?

Would that be as simple as a custom action as well? If so, what kind? Am I getting into InstallScript territory? Do I want to edit the database on the fly?

Any help would be appreciated.
0 Kudos
Level 3

We encountered the same problem. In older versions of our software, I'd have two separate projects, but with Installshield 2009, I really wanted to leverage multiple Release/Product configs in one single Installshield project.

And for us, it wasn't just changing INSTALLDIR. We have two different company names and web URLs for the Add/Remove (ARP*) properties.

To solve this problem, I used a different technique. Rather they try to a accommodate multiple configurations in the output MSI (using Conditions) I perfer to add the necessary logic to the build script. Our build script already takes a command line input for the release and configuration (which become the -a and -c parameters for IsCmdBld), along with a path to the project and various other settings, so all the necessary information exists.

A build script can read the ReleaseFlags for the specific Config/Release that is to be built, and use this information as inputs to the Installshield automation to reconfigure the project.

You can use the ISWiRelease Automation object to get the ReleaseFlags property. Alternatively, you can read the project directly with xml or msi APIs (based on how you saved the project).

As ReleaseFlags are also used by the Installscript compiler, I pre-pend any of my property overrides with an underscore "_" to avoid name collisions with other pre-defined properties. This also prevent any stepping over "real" releaseflags which maybe used by Features.

For example, I have ReleaseFlags named "_INSTALLDIR=[ProgramFilesFolder]Company\Product, _ARPHELPLINK=, etc.". When the script parses this line, it takes everything with an "_", strips off the "_" and uses the items as inputs to to reset a different INSTALLDIR, or remap default property table entries for that particular media using Installshield Automation. Once the project is resaved, the script continues on to IsCmdBld to build the project.

And for your EULA issue, I imagine you can use these flags to control other build settings (i.e. use it to set a variable which can trigger renaming the directory in your build script for you pick up your EULA files, etc) for further tweaks.

If you decide to use this idea, I recommend that you copy the project to a subdir based on the config/release name you are building before opening the project and make changes. This will avoid any collisions between different config/releases.
0 Kudos