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 Comments
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?
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.
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.
Post a Comment