Skip to content

The case of the missing Mergemod.dll in WiX v3.0.4123

There’ve been a couple of reports that WiX v3.0.4123 doesn’t include mergemod.dll. That’s unfortunate because it’s a really annoying bug and worse, I was the last one to touch mergemod.dll (to fix 1965131) so it was probably my fault.

I couldn’t reproduce the problem, however; mergemod.dll was present in Wix3.msi, Wix3_x64.msi, and wix3-binaries.zip. I was about to ask for install logs to investigate when a likely cause occurred to me. The bug fix was to revert from a version of mergemod.dll with a bug to a prior one that doesn’t have the bug. Unfortunately, downgrading files is problematic with major upgrades: Windows Installer wants very much to keep higher-versioned files around. After all, the latest version probably has all the latest bug fixes, right?

If you install WiX v3.0.4123 over v3.0.4116, the log will contain a line like this:

MSI (c) (34:D4) [10:47:26:734]: Disallowing installation of component: {AAF02F71-9684-4F4F-8EEA-FC99A61EAA9A} since the same component with higher versioned keyfile exists

Simple workaround: Uninstall the earlier version of WiX, then install v3.0.4123.

Comments 3

  1. Alasdair King wrote:

    Hey, so what would be your take on how to best handle this situation?

    1 Change the installer so it automagically uninstalls the old version before installing the new – need to stop it checking for old components to skip, too. Most Installer work.

    2 Hack the old DLL to increase the version number, so you don’t have to change your installer. Might need to re-sign the DLL. Least installer work, breaks DLL versioning.

    3 Stop the installer installing if the old package is still installed. Most user pain.

    4 Something else?

    Posted 03 Jun 2008 at 02:40
  2. Bob Arnson wrote:

    Alasdair,

    With a bootstrapper/chainer, you could do the uninstall from it which would prevent the problem. The problem is during the major upgrade, MSI doesn’t want to downgrade the file.

    Posted 03 Jun 2008 at 07:54
  3. Christopher Painter wrote:

    I used to have this problem at Continental Airlines all the time because I had internal VB6 teams and external vendors that I was repackaging that just refused to follow proper versioning practices. Ya, I know.. I tried to get them to change the ways but thems the breaks.

    The problem was easily solved by `Always Overwrite` ( not AMUS… an InstallShield feature that increments the File table to the upperbound ) and I never saw any adverse effects.

    Posted 17 Jun 2008 at 20:36