InstallShield - Building multiple releases with MSBuild

A while ago I encountered this problem: I had an InstallShield project in Visual Studio IDE. The project had 3 releases and I wanted Visual Studio to build all 3 releases at every build.

InstallShield's Visual Studio project doesn't inherently support this. It allows you to select one of the releases in the solution's Configuration Manager dialog, and this release only gets built when you build the solution. So in order to build 3 releases I needed to build the solution 3 times - each with a different release selection in Configuration Manager.

To overcome this I added an empty project to the solution where I called InstallShield's command-line builder IsCmdBld 3 times - one for each release.

This involves some manual changes to the MSBuild file:

First we create a project configuration for each release. It will allow us to select 'Release', 'Release_1', 'Release_2' or 'All_Releases' in VS Configuration Manager dialog.

<PropertyGroup Condition=" '$(Configuration)' == 'Release' " />
<PropertyGroup Condition=" '$(Configuration)' == 'Release_1' " />
<PropertyGroup Condition=" '$(Configuration)' == 'Release_2' " />
<PropertyGroup Condition=" '$(Configuration)' == 'All_Releases' " />

And create an ItemGroup for target batching. Target batching directs MSBuild to execute the target once for each release that we want to build - resembling a 'for-each' loop in programming. Notice the condition attribute which creates each item only if its own configuration or All_Releases was selected.

<ItemGroup>
 <IS_Release Include="Release" Condition="'$(Configuration)' == 'Release' OR '$(Configuration)' == 'All_Releases'">
  <Name>Release</Name>
 </IS_Release>
 <IS_Release Include="Release_1" Condition="'$(Configuration)' == 'Release_1' OR '$(Configuration)' == 'All_Releases'">
  <Name>Release_1</Name>
 </IS_Release>
 <IS_Release Include="Release_2" Condition="'$(Configuration)' == 'Release_2' OR '$(Configuration)' == 'All_Releases'">
  <Name>Release_2</Name>
 </IS_Release>
</ItemGroup>


Now we'll create the 'Build' target. To tell MSBuild that this target should be called once for each release we set the 'Outputs' attribute to an item metadata.

<Target Name="Build" Outputs="%(IS_Release.Name).NeverToExist">
 <Exec Command="IsCmdBld.exe -p &quot;$(IS_ProjectFile)&quot; -a &quot;Default Configuration&quot; -r &quot;%(IS_Release.Name)&quot; -b &quot;$(IS_BuildDir)&quot;" />
</Target>

I've passed these command line arguments to the command-line  builder:
-p "project file path"
-a "configuration name"
-r "release name" (This is the batching ItemGroup)
-b "build folder"
There are other parameters which you can explore in InstallShield documentation.
I had to wrap each parameter with " which denotes the " character in XML

The above code contains some properties the I've omitted for readability - Configuration, IS_ProjectFile, and  IS_BuildDir.

Now I can build one of the releases, or all of them at once - which is what I want to happen in the nightly build.

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.

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