Installing a Suite: Package Operations

A Suite installation is, at its core, a collection of packages. These packages can be MSI installations, MSP patches, or EXE files that are generally installations themselves. When it comes time to install, maintain, or remove your Suite, the Suite setup.exe does this by executing package operations. The operations that setup.exe will choose to run are controlled by several things. First, is a package already present and is it eligible on the target system? Next, which mode is the Suite running in, and has this package’s associated features been selected or unselected? Finally, which operations does this package support? Once setup.exe has chosen the operations for each package, it will execute them in the order that the packages are listed. The available operations and the package order are shown in the Packages view of a Suite project.

So what do these operations do?

Install

Almost all packages will have an install operation. This operation is executed to install the package onto the machine. The Suite setup.exe may choose this operation during either a first-time installation, or when a feature is turned on during maintenance. For an optimal Suite experience, either use an MSI or MSP package, or make sure an EXE package’s command lines will run it silently. If the package can be configured by your customer, create wizard pages for your customer to configure, and pass the associated properties to the packages through the command lines.

Remove

This operation is executed to uninstall the package from a machine. Packages that we consider “primary” should have a remove operation, but it may be desirable to leave “dependency” packages on a machine. The InstallShield setup.exe may choose this operation when a feature is turned off during maintenance, or when the Suite is uninstalled. Like during installation, an EXE package’s command lines should run the package silently. Note that a Suite can only install MSP packages; removing them requires removing the base MSI package.

Repair

This operation is executed to invoke the repair functionality offered by some packages. Those packages, generally MSI packages, should have a repair operation. The Suite setup.exe may choose this operation only when it is being repaired as part of maintenance. While MSI packages get this for free, EXE packages will need special handling and should be configured to run silently, or should not have a repair operation.

Modify

Packages that have feature selection of their own may offer a modify operation. This operation is executed to perform that modification. The Suite setup.exe may choose this operation when the Suite feature selection changes indicate that a package’s feature should be added or removed. Currently there is no way to configure the relation between a Suite feature and a package feature in the InstallShield IDE so you must manually edit the .issuite file’s XML to use this capability. It is configured in the Install attribute of a Selection element by appending a colon and the package’s feature name to a package GUID, e.g.:

<Selection Name=”Spellcheck” DisplayName=”ID_SPELLCHECK” Install=”{PACKAGE-GUID-HERE}:dictionary”/>

Note that a package GUID is not the same as an MSI’s package code; the package GUID merely identifies the package to the Suite.

Operator?

InstallShield’s Suite installation has built-in knowledge for handling MSI and MSP packages, including how to detect them and configure implicit command lines for their operations. You can override the detection, but the only way you can modify their command lines is by passing properties to the underlying MsiInstallProduct, MsiConfigureProductEx or MsiApplyPatch call. This means logging and UI verbosity parameters do not work. If you need to log your MSI package installations, consider specifying the MsiLogging property, or set the logging policy on your test system.

For EXE packages, however, you have full control and must ensure all enabled operations yield the desired behavior. Note that sometimes you can take shortcuts. Instead of calling the original setup.exe of an InstallScript setup in a Remove operation, you can include an uninstallation response file (uninstall.iss) in your support files and call the following to avoid a requirement to cache its installation files from your Suite:

“[ProgramFilesFolder]InstallShield Installation Information{PRODUCT-GUID-HERE}setup.exe” -s -f1″[SETUPSUPPORTDIR]uninstall.iss” -remove_only -runfromtemp -clone_wait

If you really need to configure a full msiexec command line, perhaps to show its dialogs because it won’t take properties on the command line, you can create an EXE package for your MSI installation. Call something like this for installation:

“[SystemFolder]msiexec.exe” /i “[ISPREREQDIR]your.msi”

For removal, call something like this:

“[SystemFolder]msiexec.exe /x {PRODUCT-CODE-HERE}” /qb

This has the downside of preventing the Suite from showing the MSI progress messages from this package, and requires you to provide a detection condition, but could be the ticket out of a tricky situation.

Package operations are just one of the factors that determine the run-time behavior of Suite installations. Next week, we’ll explain mode conditions and tell you how to configure some advanced mode behavior.

3 comments on “Installing a Suite: Package Operations

  1. Nat5150 on   # Reply

    Suites look promising. I use to use wisescript/sms installer to build little install wrappers, when various steps were required, such as chaining some msi’s, exe, and some command line items. Is there any way to simply call a direct command line from a suite step? Such as, killing a task, or service, with just a command, instead of having to script it? I’d like to know, and thank you.

  2. Michael Urman on   # Reply

    Hi Nat5150! Suites don’t currently have a good way to just run arbitrary commands. You can put arbitrary exe calls in packages, but if the engine cannot detect the change in machine state, it will think the package failed its install or remove operation. Your thought about including them as a script in another package might be best approach because the core package would fill the need for a detectable state change. Longer term, perhaps we should consider adding pre- and post- commands to package operations.

  3. Rhyan on   # Reply

    Also works if you have a RDP connection to the seevrr. However you need to be running in full screen mode for the key combination to be sent to the seevrr not your local machine. (Assuming that is the way that you have your options set.)

Leave a Reply

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