header image ≡ Menu

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.

Comments on this entry are closed.

  • Pingback: Did you know these Windows Installer File Types?

  • Kiran

    How does merge module eliminate version clashing, can anyone little bit elaborate with example.

  • msigeek

    When a merge module is merged into the .msi, all the info and
    resources required to install the components delivered by the merge module are incorporated into
    the application's .msi file itself. Because all the information
    needed to install the components is delivered as a single file, the use of merge modules can
    eliminate many instances of version conflicts, missing Registry entries, and improperly installed files.

    For example, if the Crystal Reports is been added as a Merge Module, it would avoid different microsoft applications using different versions of crystal report dlls. Also, as we have the signing and GUID of MSM components, even Installer takes care of reference counts and version clash.

  • Bhuvana

    It is recommended that a new merge module should be created for each successive version of a component in order to avoid version conflicts.
    Check the following Microsoft KB for MSI DB properties to handle reference count & permanent explicity.
    http://support.microsoft.com/kb/255684

  • Bhuvana

    The following link has more information on creating merge modules in general and in Wise Package Studio.
    http://www.purepackaging.com/mergemodules.php

  • Pingback: Did you know these Windows Installer File Types?

  • Pingback: Webinar: Best Practices for Building Installation in Visual Studio 2010

  • Justanotherperson

    And what about the joy of 3rd part merge modules…and patching…and security?

    Security vulnerability #473 in Product that you have in 48 packages.

    First, you are assuming that the said 3rd party vendor updates their MSM’s as quickly as they do their installs, and secondly that they do at all.

    Then you still have to go and update all of them.

    MSM’s were a nice concept that turned into something that ideally I would avoid almost always.