Defining Conditions in a Software Installation Suite Project: 6 Critical Tips

Conditions play a critical role in building a successful Suite installation.  The tips below can be a big help and save time when using InstallShield’s Suites builder.

Tip 1: Define an Eligibility Condition for Each .exe Package to Prevent Downgrades

InstallShield creates an eligibility condition automatically for each .msi package in the Suite project by default; the eligibility condition checks to ensure that a later version of the package is not already present on target systems.

For .exe packages, you’ll want to mirror the same behavior: create an appropriate eligibility condition to ensure that the Suite installation does not downgrade your product by allowing an earlier version to install over a later version.

Note that if your product supports side-by-side versions of, say, version 3 with version 4 on the same system, ensure that your conditions support this. If your product does not support these versions on the same system, ensure that your conditions block this scenario.

Tip 2: Consider Defining an Eligibility Condition for Each Package to Check for Requirements and Dependencies

A package may fail to install or the product may not run as expected on target systems that do not meet its requirements (such as the minimum operating system version) or that do not have its dependencies (such as the .NET Framework, Microsoft SQL Server, or a third-party library). To prevent the Suite package from attempting to download (if applicable) and launch packages on a target system on which they will fail, define an eligibility condition that checks for requirements and dependencies. And whenever you have a package that contains one or more launch conditions, ensure that you add corresponding eligibility conditions to the package.

Because .msp packages require their target .msi package to be present, create an eligibility condition that checks target systems for the presence of the product that you want to update.

Tip 3: Review the Default Exit Condition for Relevance

By default, when you create a new Suite project, InstallShield automatically creates an exit condition that aborts the Suite installation if none of the primary packages are eligible for installation. The exit condition has an Eligible Package type of condition check, and it uses an asterisk (*) in the condition’s package ID setting as a placeholder for each primary package’s ID.

You can indirectly control this default exit condition by modifying the eligibility condition of each package.

The default exit message assumes that your eligibility conditions only prevent downgrades. If any of the primary packages in your project have an eligibility condition that checks for something else, you may need to edit the default message to properly reflect the reason for the Suite installation aborting.

For example, if your Suite project includes one 64-bit primary package, this package may have an eligibility condition that checks for an x64 architecture. In this case, you may need to edit the exit message and condition to account for the fact that the package is not eligible on a 32-bit target system. However, if your Suite package includes one 64-bit primary package and one 32-bit primary package, and you configure the eligibility conditions for these packages so that the appropriate one is launched on target systems that have the corresponding architecture, the default exit message and condition may be suitable as is.

Tip 4: Define a Detection Condition for Each .exe Package

Every .exe package in a Suite project must have at least one defined detection condition. The detection condition should evaluate whether the package is already installed on target systems. At build time, InstallShield combines the detection conditions from all of the primary packages in a Suite project to form the Suite’s mode condition.

The Suite Setup.exe file can determine whether an .msi package in the Suite installation has already been installed on target systems. It can also determine whether an .msp package in the Suite installation has already been applied to an earlier version of the product. Therefore, manually defining a detection condition for these two types of packages is not a requirement.

Tip 5: Be Very Explicit

Make sure that you are creating conditions for all of the possible results; that way, you have full control over the appropriate behavior. For example, if you are checking for a specific version of a file or for a particular registry value, make sure to also check for the existence of the file or registry entry. Sometimes a missing file is fine but a given version number of a file is bad; sometimes a missing file is bad.

Test your conditions on various target systems and under different scenarios to make sure that the Suite installation behaves as expected. Use clean machines, machines that have earlier versions of your products, and machines that have the current version. Also consider mocking up a future version of your product to test that your current installation does not downgrade future versions.

Do you have any tips on conditions to add?  Are your conditions simple or complex?  If you have advice to share, jump in.

Don’t forget these helpful resources:

Leave a Reply

Your email address will not be published. Required fields are marked *