Thursday, March 14, 2013

Custom actions come in triples

Custom actions allow us to extend the standard Windows Installer functionality.
We can call JScript, VBScript, DLLs, or an executable. Each of these may be installed during the deployment, be embedded within the package, or already present on the target platform.

Commonly a custom action makes changes to the target platform - such as writing to files, executing DB scripts, writing to registry or any other modification.

This is all well if the deployment finishes successfully. However what would happen were the user  to click 'Cancel'? Or if some error happened during the deployment?

In these cases Windows Installer executes a rollback script starting at the action that failed/cancelled and going backwards.

The aim of rollback actions is to undo any modification to the target platform and revert the system back to the state it was at prior to the stopped installation.

Standard actions have their own rollback information written to the rollback script.
For custom actions that modify the target platform we need to provide a rollback actions.

So far we got 2 custom actions:
  1. Deferred custom actions that performs:
    1. Create backup prior to any modification
    2. Modify the target system
  2. Rollback custom action:
    1. Undo the modification (restore the backup)
    2. Remove the backup
Now we're safe on the rollback issue. However another issue reveals: If the deployment succeeds then an unused backup is left behind.
After the installation has finished successfully we can rid of it. Here comes the commit custom actions - these actions are executed after the installation has finished successfully.
A commit custom action can delete the unused backup.

Now we ended up with the trio of custom actions for any modification to the target system.

To have it all executing orderly we need to sequence the rollback action first, the deferred custom action second, and the commit action last.

EDIT:
Per Dai Corry Comment - I agree that an uninstall custom action should be added to the triple, leading us to a "Custom actions come in quadruples" conclusion.

Thursday, March 7, 2013

InstallShield: Deploying 3rd party software prerequisites

Deploying a 3rd party software is a most useful feature in software packaging. Almost any software system relies on another software to function. Probably the most common examples would be .NET framework and SQL server.

InstallShield has a lengthy list of pre-configured prerequisite that you can choose from. To select a prerequisite you simply check it in "Redistributables" view.

Sometimes however you need to deploy a prerequisite that InstallShield hasn't prepared for you. To accomplish that you create a prerequisite definition in "Prerequisite Editor" (Go to Tools->Prerequisite Editor) and it will add to the list.

Creating prerequisite can be divided into two phases:

  1. Determining whether or not the prerequisite should be deployed. For instance by checking if the prerequisite is already installed on the target machine
  2. Deploying the prerequisite (assuming the answer to the 1st phase was yes)

To determine whether or not a prerequisite should be deployed you perform tests on the target system.
InstallShield lets you test it by:

  • Looking for the existence of a registry key
  • Comparing the data of a registry value
  • Comparing the data of a registry value assuming the data is a version string
  • Testing for the existence of a file
  • Searching for a given file with a specified date
  • Searching for a given file file with a specified version
  • Checking the OS version on the target machine
The "Prerequisite Editor" dialog has more options that you can explore (deployment command line, exit code handling, etc...)


Sharing my application packaging experience

Hi,
For some years I've been consulting, tutoring, and packaging applications to Windows platforms.
Over these years I've encountered many confused developers who struggled with application packaging  without having proper knowledge of this issue
Many S/W companies simply purchase a license for a packaging tool (InstallShield, Advanced Installer etc...) and let one of the developers find their way. Usually the assumption is that the UI will lead them the way to a proper package.

Well... In most cases the poor developer manages to build a package. Alas the package is far below professional standards and somewhere down the road it will float (when the installation rolls back, an update is released, or whatever other obstacle is encountered)

In this blog I'll share my experience to help packagers understand and improve their packaging skills. While not a replacement for thorough learning it'll give some references and rules-of-thumb

Nir