6 Best Practice Tips for Defining Conditions in a Suite Project

By Debbie Landers

In my last InstallTalk post, I explained some of the basics on defining conditions in a Suite project in InstallShield. In today’s post, which is sort of part 2 on conditions, I offer some best practice tips and present a few sample conditions.

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. (For more information, see John Cresswell’s previous post on mode conditions in Suite installations.)

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.

Tip 6: Test, Test Some More, and Then Test Again

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.

Example Conditions

Following are some examples that put some of the aforementioned tips into practice.

Example 1

You may want to include in your Suite project a package that installs Windows Installer 4.5 if Windows Installer 3.0 or earlier is present. For the purposes of this example, let’s ignore the platform conditions that you would want to define for this package, and concentrate on the detection and eligibility conditions for the Windows Installer engine, msi.dll.

In this scenario, the package needs a detection condition to check whether Windows Installer 4.5 or later is present, and prevent the package from running in that case. The package also needs an eligibility condition tree; the package is eligible for installation if the target system has version 3.1 through 4.1.

Example 2

If your installation needs to check target systems for a specific version of a file, you may need to create a condition tree that checks (1) for that specific version, and (2) for the presence of that file. Checking for both of those conditions gives you the flexibility to trigger different behavior, depending on how both of those conditions are evaluated. The following screen shot shows a condition tree in that checks for a specific version or newer of a file, as well as the presence of that file.

In the above example, the condition tree checks for the presence of a particular DLL and also looks for version 4.0.0 or later of that DLL. Both of the conditions must evaluate as true in order for the condition tree to evaluate as true. That is, if either the file is missing in the Program Files folder, or an earlier version of that file is present, the condition tree evaluates as false.

Example 3

If your installation needs to check for the presence of a specific service pack of a certain version of Windows, or any newer or earlier version, ensure that you create the condition tree in such a way as to trigger the required results.

For example, the following screen shot shows a condition tree that evaluates as true if the target system has at least service pack 1 of Windows Vista (OS version = 6.0) or if the target system has Windows 7 or later (OS version = 6.1).

The results are very different if you create a check for version 6.0 or later with service pack 1 or later. In this particular case, the condition requires that if the target system has Windows 7, service pack 1 must be present; otherwise, the condition tree evaluates as false. Although it is possible that you may need to check for service pack 1 or later of Windows 6, as well as service pack 1 of other later versions of Windows, in many cases this will result in unexpected behavior.

What sort of conditions do you need to check on target systems, and how complex are your condition trees? Feel free to share your own circumstances by posting comments.

To learn about other features and capabilities new in InstallShield 2012, watch the What’s New in InstallShield 2012 Webinar.