In Defense of Merge Modules

Neil Sleightholm recently commented:

"Personally I never use merge modules unless I am forced to!"

It's an interesting perspective and I invite Neil to tell more ( as an aside, I'm always interested in guest bloggers on the Deployment Engineering team.  Diversity in Opinion is always a good thing ).  Until then, I wanted to give a few of my thoughts.   

Let's begin by reviewing Windows Installer Tao Rule # 43

Rule 43: Think carefully about Merge Module Patching

Merge modules provide a standard method for delivering Windows Installer components and setup logic just like any redistributable software. For all practical purposes any MSI package can consume a merge module and start using the functionality exposed by the merge module. However, the servicing story of such an MSI package has a huge flaw. 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 bottom-line of the story here is:

•Do not consume merge modules of vendors who do not promise to fix their merge modules promptly when bugs arrive

•Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame

Merge modules are great to use for distributing authoring and building of your setup. However, if you intend to redistribute an MSM externally, you should review the servicing implications. If you can tightly control the MSM consumers and identify the relevant products, then it’s possible to service them with a single MSP (multi-product targeting). Otherwise the recommendation is to provide your technology as an MSI that must be chained into the setup

Let's begin with a little history lesson. Microsoft used to use Concurrent / Nested Installs and Merge Modules as a deployment option for Microsoft SQL Server Desktop Engine. Then along came some really nasty security vulnerabilities that exposed a glaring problem in servicing these products that were embedded in other products. Network / Systems Administrators simply couldn't patch there production systems easily to eliminate these worms. Then Microsoft started telling developers to not use these technologies and instead use Micro-Packages to deliver them. After awhile, the message mutated into something along the lines of "merge modules are evil".   Then there was the little problem that MSI doesn't actually provide a decent bootstrapper / chainer to put all these packages together and the proliferation of packages has made Add/Remove Programs look like total chaos.  

Now let's go back and re-read Rule #43 with a little emphasis on the parts that I find interesting:

Rule 43: Think carefully about Merge Module Patching

Merge modules provide a standard method for delivering Windows Installer components and setup logic just like any redistributable software. For all practical purposes any MSI package can consume a merge module and start using the functionality exposed by the merge module. However, the servicing story of such an MSI package has a huge flaw. 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 bottom-line of the story here is:

•Do not consume merge modules of vendors who do not promise to fix their merge modules promptly when bugs arrive

•Be prepared to handle the heat when bugs are found in your merge module causing issues for others’ products that have consumed your merge module and you get to put out the flame

Merge modules are great to use for distributing authoring and building of your setup. However, if you intend to redistribute an MSM externally, you should review the servicing implications. If you can tightly control the MSM consumers and identify the relevant products, then it’s possible to service them with a single MSP (multi-product targeting). Otherwise the recommendation is to provide your technology as an MSI that must be chained into the setup

OK, so what am I getting at?   Yes, it's true that when I put merge modules in my installs from third parties ( typically Microsoft .. how ironic )  that the quality of my installs go down.   And it's true that Microsoft doesn't promise to provide fixes and updates to these modules and in many instances they don't provide MicroPackages to redistribute either.    So what's my alternative?  Break the component rules and author my own components for another companies  resources?   Yup, this is an ugly problem that's never solved except by not taking dependencies on those components and moving to newer technologies that get more love from third party vendors.  Still, I'm writing the install not the application so I don't typically get to make that call.

However,  I am certain that using merge modules internally  to distribute setup development is a good thing.   Comparable and even better in some situations then using  WiX Fragments / Libraries /  Binary Libraries or InstallShield Developer Installation Manifests.

First, Merge Modules are STANDARD and can be consumed by installers ranging from InstallShield to WiX.   Try consuming an InstallShield DIM in WiX or a WiX Fragment in InstallShield. 

Second, merge modules are atomic collections of components and setup logic.  This is actually fairly similar to WiX Fragments which according to their own documentation are also atomic and immutable.  WiX Binary Libraries and MSI Merge Modules both aim to solve similar problems.

Sure, using Fragments can speed up your build and give you a bit more flexibility ( like including two components in a fragment but Referencing them into two different features ).    However, you can do the same thing with merge modules by creating multiple merge modules with module dependencies to describe component / feature relationships.  With a little bit of creativity, Merge Modules can even be used to encapsulate AppSearches, CustomActions, Dialogs and more.

Over the last five years I've developed an architecture where I use an InstallShield Basic MSI project to describe a feature tree and product configurations to describe which features to consume.  This serves as a fishbone that I then flesh out with dozens to hundreds of merge modules and create dozens of product installers with.   I use Major Upgrades as my servicing strategy and the result is I've never had any problems that were caused by the use of Merge Modules.

In summary, you don't have to have a monolithic InstallShield project for each of the installs you own.  You can split it out and reuse components and logic through merge modules and not increase the fragility of your install.   In fact, you can realize considerable savings by eliminating wasted effort and decreasing the frequency of bugs in your baseline.

Yes, I will admit it:   I use Merge Modules and I'm OK with that.   Still,  I will be working on Fragment support for IsWiX.