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

Posted on by

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.

3 thoughts on “The case of the missing Mergemod.dll in WiX v3.0.4123”

  1. 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?

  2. 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.

  3. 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.