Windows Installer, Application Compatibility and Deployments

Redistributing Application Components using Merge Modules

Most developers understand the benefits of writing reusable code. It makes sense to use that piece again when you need the same functionality. The more pre-tested software you can reuse, the fewer bugs you’re likely to have in the final product.

Merge modules extend the notion of reusable components to the software installation process. Once you’ve developed a way to install a reusable component, you can also reuse the installation process!

mergemodulesMerge modules are pre-compiled libraries of components like files, registry, and other system changes which install a discrete portion of the application. This common module can be added to the various applications, instead of adding individual components to different msi files. They cannot be installed alone. they must be merged or added to an msi file to install it.

Merge modules are a mechanism that allows many Application Publishers to prepackage components, sign them and share these standard modules!

A merge module is similar in structure to a simplified Windows Installer .msi file. A merge module(msm file) contains files, DLLs, ActiveX components, registry entries and some system configurations like environment variables that make up these runtimes.

The use of merge modules can eliminate many instances of version conflicts, missing Registry entries, and improperly installed files!

As mentioned before, a merge module cannot be installed alone, it must be merged into an installation package using a merge tool. Developers can also create new merge modules by using many of the same software tools used to create a Windows Installer installation package, such as the database table editor Orca provided with the Windows Installer SDK.

Developers can use this method to merge modules or obtain a merge tool from an independent software vendor like Wise, InstallShield etc.

When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application’s .msi file. The merge module is then no longer required to install these components and the merge module does not need to be accessible to a user.

Merge modules is a tool for the developer, not for the end user!

Summing up, points to remember about the merge modules:

  1. All the information required to install a shared file is delivered to the installer in a single, standardized .msm file.
  2. Eliminate many instances of version clashing, missing registry entries, and improperly installed files.
  3. Traditional installers keep an incremental reference count of the number of applications using a shared file, but not the name of the application. If shared files are installed from .msm files, the Windows installer can keep a correct reference list of applications that use those shared files.
  4. Windows can better avoid deleting shared resources used by any application until the last application using them is uninstalled.
How-to Windows Installer, Application Compatibility and Deployments

Merge – Merge Module Contents to an MSI

There is always a need for a merging tool when we want to add the components in a merge module to our Installation Package(MSI). All the major packaging tools offer this functionality. There’s also an utility called MsiMerg.exe that ships as part of the Windows Installer SDK. 

The syntax for using this utility – msimerg.exe {base db} {ref db}

It turns out that the base database is the Installer package that we’re merging to, and the reference database is the merge module that we want to add to the package. 

Eg: msimerg ABC10EN.msi comcat.msm 

This will add the information from the comcat merge module to the ABC10EN Installer package. If there are any errors during the merge, it will create a table named _MergeErrors for our further inspection.