By Debbie Landers
In a recent InstallTalk post, Michael Urman, one of the software engineers on the InstallShield team, introduced you to Suite projects, which are new in InstallShield 2012, and touched on some of the advantages of Suite installations over other technologies, such as Windows Installer package chaining and InstallShield prerequisites.
This post presents a number of new Suite-related terms and concepts.
This is the file extension for the XML file that InstallShield uses for Suite projects.
A package that is designated as a dependency package may be a required technology or product that must be present in order for a package to be installed or a product to be used, but it should not be a factor in determining which mode is used to run the Suite installation.
A package that is designated as a primary package of the Suite project is a main part of the Suite installation. At run time, if all of the primary packages in the Suite installation are absent from the target system, the Suite installation runs as a first-time installation. If any of the primary packages in the Suite installation are present on the target system, the Suite installation runs in maintenance mode.
This is a code that uniquely identifies a Suite installation.
A Suite installation is a bootstrap application that packages together one or more separate installations as a single installation while providing a unified, fully customizable user interface. It uses the next-generation setup launcher (Setup.exe) to conditionally run one or more .exe and .msi packages and apply .msp patches as needed on target systems. The following diagram shows the various parts of a Suite installation.
Parts of a Suite Installation
At build time, InstallShield uses the various sections of the .issuite file—the Suite project’s XML project file—to create Setup.xml and Setup_UI.xml, and bundle these together with the Suite’s packages and other files that are required to run the Suite installation. The resulting Suite installation includes the following files:
- Setup.exe, which contains the Suite engine
- Setup.xml, which describes the packages that are in the Suite, the conditions under which they are launched, and the string entries that are used in the wizard user interface of the Suite
- Setup_UI.xml, which defines style settings, layout information, and other UI parameters for the Suite’s wizard user interface
- SetupUI.dll, which consists of the Suite library that is used to render the Suite UI
InstallShield also gathers the packages in the Suite project and sets up the folder structure, if applicable, for the packages and their associated uncompressed files. In addition, InstallShield incorporates the Suite’s support files, which are resources such as EULAs and image files that are shown on wizard pages.
When an end user launches the Suite installation, the Suite engine reads the Setup.xml file, loads the SetupUI.dll file, evaluates the conditions that are defined for the Suite and each of its packages, follows the instructions in the Setup.xml file, (if applicable) downloads packages and files that are needed on the target system, runs the packages that need to be run, and cleans up resources.
A Suite package is any of the following types of files that you can include in a Suite project:
- Executable files (.exe), including Windows Installer–based and non–Windows Installer–based installations that you want to be run on target systems
- Windows Installer packages (.msi) that you want to be run on target systems
- Windows Installer patches (.msp) that you want to be applied on target systems
When you are adding any of these types of packages to your Suite project, you have the option to also include any additional folders and files that need to be included with uncompressed installation packages.
Internally, when we started developing the Suite support, we referred to these files as parcels, which is helpful to know if you are looking at the Suite project file (.issuite) or the Suite’s Setup.xml file, since the XML code uses parcel to identify packages.
Suite Run-Time Behavior
This is the location where the Suite installation caches the Suite package and other files that should be stored on target systems.
This is a statement of logic that compares a value of a setting or a property or determines whether the value is defined. Suite projects support various types of conditions:
- Exit conditions—this type evaluates whether the target system meets various requirements for the Suite installation. If the requirements are not met, the Suite installation displays an error message and the installation exists.
- Feature condition—this type evaluates whether the feature should be selected for installation by default on the InstallationType wizard page.
- Detection condition—this type is defined for a package in the Suite project. It evaluates whether the package is already installed on target systems.
- Eligibility condition—this type is defined for a package in the Suite project. It evaluates whether the target system meets the requirements that are necessary for the package to be run.
When you add an .msi or .msp package to a Suite project, InstallShield automatically configures a detection condition and creates a modifiable eligibility condition for the package.
When you add an .exe package to a Suite project, you must define at least one detection condition.
A Suite debug log is a file that contains logging information about the Suite installation. It may be helpful when troubleshooting. To generate the log file, pass the /debuglog parameter to the Suite Setup.exe file when launching it through the command line. To specify the name and location of the log file, pass the path and name, as in the following example:
The mode indicates the state in which the Suite installation is running. Available modes are install, remove, maintenance, modify, repair, and stage.
When an end user double-clicks a Suite Setup.exe file, the mode is always either install or maintenance. The other modes are available through the UI of the Suite installation or when the Suite Setup.exe is launched through the command line.
See also operation, which is a similar term that is applicable to the packages in a Suite installation.
Note that the mode does not necessarily indicate the state for each package in the Suite installation. For example, it is possible that the Suite installation may be running in maintenance mode, but one of the packages in the Suite may be launched through an install operation.
The operation indicates the state in which a package in the Suite installation is running. Available operations are install, remove, maintenance, modify, and repair. The remove, repair, and modify operations apply to .exe and .msi packages, but not .msp packages.
See also mode, which is a similar term that is applicable to the Suite installation.
Staging occurs when the Suite installation copies (and downloads or uncompresses if applicable) the Suite’s data files to a directory that is specified by the user. The Suite installation does not actually launch the packages in the Suite installation during the staging part of the installation.
You can launch the Suite installation in stage-only mode from the command line by passing the /stage_only parameter to the Suite installation. This option is similar to the administrative command-line parameter (/a) that is available for Basic MSI Setup.exe launchers.
Suite User Interface
An action is behavior that an end user triggers when using some of the various wizard interface controls. For example, you can add a Print button to a LicenseAgreement wizard page, and define a print action for that button control; when an end user clicks the Print button, the Print dialog box opens, enabling the end user to print the license agreement.
Other types of actions can launch a Browse for Files or Folders dialog box, launch a secondary window as a modal window, jump to a different wizard page, open a file or Web page, launch an installation, and set a property.
A binding is a way for tying the visible state of a wizard page to the value of a Suite property. It is also used behind the scenes to tie the text of a label or other control to a property.
command link button
A command link button is one of the new types of built-in controls that you can add to the wizard user interface of Suite projects. This type of control offers a set of mutually exclusive options, similar to radio buttons. Each option includes an icon, a command link label next to the icon, and an optional supplemental explanation about the option.
The MaintenanceWelcome wizard page that is included in Suite projects includes three command link buttons:
Command link buttons on a Suite wizard page
A secondary window is a UI element of a Suite installation. It is also known as a pop-up window. Suite projects contain a number of standard predefined secondary windows that you can customize as needed. You can also add your own secondary windows to a Suite project.
See also wizard page.
A support file is a resource file that the Suite installation needs at run time. The resources are installed to the target system for use only during the installation process and then automatically removed when the installation is complete. Examples of resources that may be included in a Suite installation are EULAs, images, and Flash files that are displayed on the Suite’s wizard pages.
A wizard page is a UI element of a Suite installation. It is analogous to dialogs in Basic MSI and InstallScript installations. Suite projects contain a number of standard predefined wizard pages that you can customize as needed. You can also add your own wizard pages to a Suite project.
See also secondary window.
A release flag is an identifier that you can assign to features and packages in a Suite project for use in build-time filtering.
This background lays the foundation for many of our upcoming InstallTalk posts on the Suite support that’s new in InstallShield 2012. We’ll cover topics such as customizing your Suite installation’s UI, defining complex conditions that a Suite installation needs to evaluate before downloading and installing various packages, and troubleshooting tips.
We’ll also cover various aspects of DIM projects, and how to use them with distributed development teams.
So make sure you stay tuned to our InstallTalk blog, and feel free to post suggestions for additional topics that you’d like to see covered.