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
- :
- Multiple releases in multiple INSTALLDIR
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
‎Oct 15, 2008
07:10 PM
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)?
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 16, 2008
03:46 AM
why don't you set your INSTALLDIR depending on conditions? use a "Set Directory" custom action.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 16, 2008
03:53 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 18, 2008
11:59 PM
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=http://www.support.com, 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.
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=http://www.support.com, 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.