Client Profile Configuration Designer "How To" Series – Configuring the UI (Part 4 of 4)

Chained installers (continued)

So far, we’ve only added a single chained installer which is just the self-extracting executable. This alone won’t install the Configurator as we still need to invoke the MSI file embedded in that self-extracting executable.

As this is a common “trick” employed by chained installers, the tool has built-in support for those kinds of chaining mechanisms through a concept of "Loose packages". A loose package is a package whose file will get generated at runtime by a preceding chained installer.

Obviously, because the tool doesn’t have intrinsic knowledge about the type of the loose package, it has to trust the setup author to provide:

• A path that will be valid at runtime; preferably a relative path to the working folder is used.
• Correct and applicable settings for the type of the loose package.

In our particular sample, we’ll add a loose command to invoke the extracted MSI installer obtained by executing the self-extracting executable using "/x:.".

To "import" a loose package, we use the same dialog as we used before to import the self-extracting executable, as illustrated below:

Notice the command being used. As installers within same product definition share the same temporary working folder at runtime, we trust to find the arrowhead_configurator.msi file as a result of executing arrowhead_configurator.exe /x:. in the same working folder (the /x:. extracts to the current folder).

The import process will be almost instantaneous as we’re not copying any physical files. We’ll specify the following settings in the various configuration places that were outlined before:

• Install arguments:
  • REBOOT=ReallySuppress (this avoids MSI to initiate a reboot by itself)
• Installation size:
  • 2000000 bytes
• Exit codes:
  • 0 – Success
  • 1641 – Success and Reboot
  • 3010 – Success and Reboot
  • Default – Failure

Finally our install order should look like:

Now that we’ve finished the payload authoring for our installation, we can take a look at the generated markup. This corresponds (almost) to the product.xml that will be generated by the build task.

Note: This product.xml format is not fully compatible with the bootstrapper and requires post-processing by the layout build task. In addition to the information required by the bootstrapper, the tool stores additional metadata required for the IDE. You can view this internal representation by holding CTRL-SHIFT when clicking the Markup button (this also applies to the skin definition markup).

Building the Project

Next the project can be built in Release mode. This will perform the following steps:

• Produce a folder layout for the entire setup package (excluding any online to-be-published packages).
• Build a CAB file containing the entire folder layout.
• Stream the CAB file in to a self-extracting EXE skeleton, producing the final self-extracting EXE.

Below is a screenshot of the output window during a build, currently in the self-extracting EXE creation step.

The produced folder layout looks like this:

An overview of the "input" folders that are part of the project itself:

• Resource contains images, license agreements, etc included during design;
• Prerequisites holds the copies of the prerequisites that were imported into the project;
• Packages keeps the copies of the chained installers, in our case just the self-extracting EXE.

Folders produced by the build system are:

• debug, which was discussed before and is used for the Preview mode;
• net, containing the physical layout of the setup package;
• sfx, the result of compressing the net folder in a self-extracting executable.

In our case, the resulting self-extracting executable contains the self-extracting executable containing the Configurator MSI package, a bunch of XML files and product definitions for online install of .NET Framework 3.5 SP1 in case it’s not already present on the target machine. Altogether we end up with a file of barely 1.18 MB that installs in 30 seconds (assuming the .NET Framework 3.5 SP1 was already installed).

Note: The resulting self-extracting executable is not Authenticode signed. Support for build-time signing might be added in future revisions.

Build-time feedback

The build system provides feedback about missing, incorrect or incomplete settings:

Another example is missing localization strings.

Publication

If publication is enabled and a homepage has been set, one can use the "Preview in browser" capability from Tools, Options.

Building the package in the Publish mode will then automatically upload the marked files, as well as the self-extracting executable, and navigate to the generated homepage:

Clicking the link downloads the self-extracting executable and allows executing it straight away.