What is a Merge Module
An easily accessible analogy for the purpose of a merge module, and it’s file format MSM, is:
MSI is to EXE as MSM is to LIB
Merge modules are single packages that include files, resources, registry entries, and setup logic to install shared components. They have the same basic format as an MSI:
- A database with the installation properties and setup logic
- A summary information stream describing the module
- A cabinet file stored as a stream inside the merge module
- The module itself is assigned a GUID and keys for every row in every table are assigned the same GUID
Within an MSI, a merge module is a single feature in its own right, therefore the MSM contains no features itself. Merge Modules can come along with dependencies, which require further MSM’s to be added to a packaging project.
During the build process from a packaging project to an actual MSI package, merge modules are consumed by the installer package files. This means that once the MSI is build, the resources which were originally bundled within the MSM are no longer distinguishable from other MSI resources. This process of integrating an MSM into an MSI is called “merging”. Therefore, after the package is built, the merge module is not a separate element anymore.
Merge Modules in RayPack
General merge module support is available in RayPack’s PackDesigner as of release 1.1. Users are able to add MSM’s to packaging projects from a management view of the Visual Designer. Raynet provides a common merge module library, which is shipped along with the RayPack application resources. Manually adding further MSM files to a packaging project is possible as well from external origins.
Additional functionality regarding MSM files will be added over time, including the ability to scan for MSM usage in existing packages, and view details regarding merge module contents from within the PackDesigner interface.
The content of the MSM library are about to be analyzed during capture processes, which will allow packagers to individually decide if resources that are bundled within an MSM should be integrated into the capture project as individual resources, or if the complete MSM with all included resources should be used instead.
Benefits of using Merge Modules
Merge modules represent a generally accepted standard for the sharing of resource bundles used within MSI based application installations. Bundling depending resources helps to avoid havoc regarding version clashing, missing single files and registry elements, and therefore installations with results that hang behind expectations.
Windows installer utilizes MSM information to keep track on the applications which actually rely on shared components. Not only by incrementing a numeric counter but by actually storing the application reference. This is a major advantage regarding save and clean system states even after complex install and uninstall sequences over extended maintenance periods. Many issues that lead into ending up in “DLL hell” can be avoided with proper resource tracking.
An additional benefit lies in the fact that MSM’s are de facto standard: they can be handled by most of the market leading installer implementations. Once run into troubles caused by proprietary formats, packagers will very soon come to the conclusion that being able to transfer intelligence freely over editor boundaries is a quite handy advantage.
For whatever that is worth to the individual user: Microsoft recommends the use of .msm files for code sharing among application installers.
Merge Modules drawbacks
Wherever is there light, there is also darkness. So let’s take a look at reasons that might prevent packagers from actually using MSM’s:
Even though merge modules are standard, not all vendors use them to capsulate their shared resources. Even Microsoft does not provide full MSM support for all of its products.
Since packages usually consist of more than just clearly distinct MSM resources, but also contain resources which are not bundled, there is potential for merge conflicts between both types of resources during the build process. What if a file is present within an MSM and as a lose resources within a packaging project? Which rules can be followed (automatically at best) to make sure the resulting MSI is shaped just as expected?
Another disadvantage is the fact that the quality of the MSM file has to be checked with separate validation routines (MergeModule.cub). If there are issues with merge modules, the packager at the end of the food chain cannot solve them in general, only individually per installer file generation.
The “Tao of the Windows Installer” explains the issue pretty clearly in rule 43:
“[…] Since the setup author who owns the MSI doesn’t own the merge module, they have no way to deliver fixes to issues that are found in the merge module, unless the merge module owner makes them available. On the other hand, the owner of the merge module has no way of delivering the fixes directly to the clients who installed the MSI built after consuming his/her merge module. […]”
The logical conclusion is to avoid merge modules of vendors with low ambitions to keep up their MSM quality by maintaining decent bug fixing and updating routines.
Summary
So, what is MSM technology – friend or foe? Well, it’s always a wise approach to keep your friends close, and your enemies even closer. Using merge modules as standard method for managing depending resource bundles surely has the potential to increase the quality of installations, since they allow cleaner maintenance procedures on the end users machine. Nonetheless, using them can only be successful in the end, when the pitfalls outlined above are considered and avoided. Therefore, merge modules might be considered as “frenemies” – a good thing to have but with a dear need to handle with care.
Read on & discuss
http://msdn.microsoft.com/en-us/library/aa369820%28v=vs.85%29.aspx
http://www.ewall.org/tech/msi/merge-modules
http://www.softwarepackaging.co.uk/mergemodules.html
http://blogs.msdn.com/b/windows_installer_team/archive/2006/06/27/648447.aspx
http://blog.iswix.com/2010/09/in-defense-of-merge-modules.html
Comments