Update an MSI Installer without rebuilding

In many development environments, updating outdated Installers of the development tools can be challenging.

In most cases, the original development environment used for generating the installer will be no longer available. In such cases, an installer can be disassembled, changes be applied and reassembled back using MS installer APIs.

Steps

1. Extract the contents of the installer to a temp location. For example,

msiexec.exe  /a xxxx.msi targetdir=d:\temp  /quiet

This step will create following file structure

d:\temp

    xxxx.msi 

    WinRoot

        Temp

              <files to be deployed>

The xxxx.msi under d:\temp is barred off the installation files, which are stored in d:\temp\WinRoot\Temp folder. Any changes required can be applied here,

2. After the changes, the MSI can be assembled back using the following command.

cscript WiMakCab.vbs d:\temp\IW_eIFU.msi  Data1  /U /E /S /C

The VBScript file WiMakCab.vbs can be downloaded from this location.

The installer file xxxx.msi under d:\temp  now will contain the new changes.

It's also possible to do much more than this, for example update GUIDs etc. This is implemented in this post.

Source and Binaries can be found here.

Easy MSI Installer Creator with Actions

Often times software, data files etc. needs to be packaged and sent across. Zip files are sufficient in most cases. However, sometimes complex deployment needs could arise, For example, multiple versions, operations on the files, etc.

Easy Installer Creator addresses this as described below:

• Standalone application – only .Net 3.5 is required
• Create layout file containing files, directories and sub directories etc by drag drop from windows explorer
• Folders can be pre configured or can be supplied on demand during installation
• Installer properties such as Manufacturer, upgrade Id, product id can be updated
• Custom file operations can be defined.
• Pre and Post deployment operations supported.
• Creates Installers (.MSI files) that support silent installation.
• Command line operation is supported for build scripts
• Templates for COM+ Server COM+ Client and WCF Server

In addition, this also comes with tools that integrate components into COM+ as discussed in the previous posts "COM+ integrated WCF Service" and "Late binding Client code generator for COM components". An example to demonstrate these capabilities is also provided. Please refer to the documentation for details.

Create a new Layout ¹

This creates a new .layout file. Files and folders can be added at root by drag and drop from windows explorer. Three options are available.

Simple – Creates a basic installer.

DCOM Server – Facilitates installing COM components in COM+ application also provides server side DCOM patching. Users can customize by editing server.vbs.

 DCOM Client - Provides client side DCOM patching. Users can customize by editing client.vbs.

Open existing Layout ²

This opens an existing layout. The tree view is populated with the file structure.

Save Layout ³

After files are added to a new layout, the layout needs to be saved to create the installer. Note that a new package code is created for every time a layout is saved. Following describes the user interface in detail.

Name of the layout and the package¹

Location of the layout file²

Version of the layout and the package³

The name and the version of the layout file. This will be embedded into the package.  The location of the layout file specifics the directory.

Set new product code to the package ⁴

It lets a new product code to be defined for the package. This will allow creation of a new product in the families of products. The upgrade code will remain same.

Scripts to run before and after the file copy ⁵

Users can configure operations to be executed before and after file copy of an installation.

Scripts to run before and after file copy ⁶

Users can configure operations to be executed before and after file delete of an uninstallation.

Command to execute before file copy during install or before file delete during uninstall ⁷

These commands typically do checks to be performed before install or uninstall. Upon exceptions, StopInstall environment variable must be set to 1 to abort.

Command to execute after file copy during install or after file delete during uninstall ⁸

These commands typically do post install and uninstall operation. Upon exceptions, StopInstall environment variable must be set to 1 to rollback.

Save Layout ¹⁰

This saves the current layout and settings to disk. The new layout will be associated with new package code, product code, and upgrade codes. The file name will be name+version.layout. Example, example_1.layout.

The pre post commands for install and uninstall commands are also stored. By default, the only files specified in the commands are added to the setup folder discussed later. Additional dependencies such as assemblies must be added to setup folder by drag drop from explorer. 

Set values for logical folders and add additional parameters ⁹

When defining a layout, logical folders can be defined whose path is inputted during installation. However, if the path is already known it can be entered ash shown below. All the logical folders defined in the layout are listed. If the input is already defined, these appear as default values during installation. The values can be entered in the second column¹. Also new parameters can also be defined by entering the name and value ³. For silent installation mode, asking user input can be turned off by checking off the ask input option ².    Note that during installation and uninstallation, an environment variable will be created for each of the parameters.

 A list of existing environment variables can be listed. ⁴

File Actions ⁴

This dialog enables defining a new custom action or edit an existing. There are 18 predefined commands. Refer to the appendix for the details. These commands cannot be edited or deleted.  New user defined commands can be defined that can also be deleted. During installation these commands are executed after the files are copied. During uninstallation, the commands are executed before deleting the files.

List of actions ¹

This is a list of all actions including built in and user defined commands.

Folder level or File level command ⁴

This indicates if a command is applicable only to a folder or only a file or both to file and folder. For example, regasm is applicable to a file. Whereas create new is applicable to a folder.

Name of the command ⁵

This indicates the name of the command. The name cannot be changed once the command created. It can be specified only when a new command is created.

Priority of the command ⁶

This indicates the priority of the command. 0 is highest and 5 is the least. Commands with highest priority are run first.

 Applicable File extensions for the command ⁷

This indicates the file extensions of the file to which this command is applicable. * indicates for all file extensions. Multiple extension can be applied separated by ;. E.g., dll;exe

Path and arguments for the command ⁸

The “Executable” indicates the path of the executable with full path. The Arguments indicates the applicable arguments. The installer passes the actual file name as last argument to the command. If Group ¹⁰ option is supported, the filenames will be combined with other files executing the same command and the arguments. The arguments within <> needs to be edited.

Wait for command to complete ⁹

This indicates that the installation or uninstallation waits till the commands are completed.

Command can be applied in group ¹⁰

This indicates that this command takes multiple files are arguments. This command is executed it will include all the files that indicate execution of this command and having same command arguments.

Command applies during Installation ¹²

This indicates that this command is available only for installation.

Command applies during Uninstallation ¹³

This indicates that this command is available only for Uninstallation.

Tool tip for the user ¹⁴

Provides useful information to the user

Update ¹¹

This will commit changes done to the command .

Add new command ²

This will add a new command. Following describe adding a new command notepad.exe.

1.       Click New²  button.

2.       Enter name⁵ as Notepad

3.       Check Leaf level ⁴

4.       Enter * for the filter ⁷

5.       Select 1 for priority ⁶

6.       Enter %windir%\notepad.exe for Executable ⁸

7.       Enter filename(s) for Arguments ⁸

8.       Leave Wait for Exit ⁹  and Support group ¹⁰ unchecked

9.       Click the Update ¹¹ button

10.   Click Save and Exit button to save the command

Note that all the fields except the name can be edited.

Delete command⁵

This will delete the selected command.

Actions on the File ¹⁶

This sets actions on the individual file and folder items. Installation actions are called after files are copied. Uninstallation actions are called before deleting the files. The physical file path is passed as last argument to the command. Based on the group action setting ⁶, the action can be combined with other files.  Arguments with <> require user inputs. For example, <app name> represents the name of the COM+ App.

Example

Creating Server Installer

Launch Easy InstallerCreator.exe  Execute following steps:

1.       Click new and select DCOM Server

2.       Add a logical folders “WCFCalc. “

3.       Rename “%Components%” to “%Calc%”

4.       Add a physical folder “server “ under example.

5.       Drag and drop files from D:\Github\TechBlog\File Utilities\Easy Installer Creator\Example\server

6.       Define custom actions as below. 

Save the layout file as below.

Click Set parameters and Save as below:

Create the installer

For more information check out the chm file.

Source and Binaries can be found here.

Digital Code Signing binaries and scripts during Nightly Builds

Digital Code signing binaries such as exes, dlls , scripts by the software supplier is now a  de facto requirement. The digital signatures not only identifies the source of the software but also  asserts authenticity. Also AppLocker  rules can be configured to check digital certificates.

Digital Code signing is usually done as part of the build process where binaries are digitally signed as they are built. However this can impose overhead and add complexities in development build environments. Also there could be older digitally unsigned 3rd party binaries supplied as a part of the software. An ideal solution would be to do digital signing as a separate step during nightly production builds as discussed below:

Concepts
A digital certificate issued by vendors such as Verisign. This is to authenticate the source of the software. It's basically cryptographic public key. 

signtool.exe from Microsoft is used for signing the binaries. For example, icudt.dll was digitally signed and after signing, the digital certificate would be embedded as shown below.

Implementation

A script is created such that

• It is invoked before creating the iso file of the software before deployment. 
• It recursively extracts binaries in msi, .zip, cab files, digitally signs them using signtool.exe and packages back.

Extracting and packaging a msi file is done using installer APIs as discussed here.

Extracting and packaging a cab files is done using CabArc.Exe.

Extracting and packaging a zip files is done using 7z.Exe.

Source and Binaries can be found here.