Merge module install failing during major upgrade

Question

I have an InstallShield InstallScript MSI project that contains the FLEXnet Connect without Software Manager merge module. The version of this product is 6.0.32. I created a second installer for version 6.1 that also contains the FLEXnet Connect without Software Manager merge module. When I perform a major upgrade on a system that contains the 6.0.32 version I get a message in the MSI log stating:

Disallowing installation of component: {FF970098-B748-427B-B946-AA8E1A1F82AD} since the same component with higher versioned keyfile exists

The component is referencing the isusweb.dll file located in the FLEXnet Connect folder.

It looks like this check occurs prior to the 6.0.32 product being removed. The install proceeds to remove the 6.0.32 product, which removes isusweb.dll. During the 6.1 install the isusweb.dll is not put back because of the component version check.

The upgrade succeeds. When I attempt to run the application from a shortcut it verifies the components. Since the isusweb.dll is missing the MSI attempts a repair, then cannot find the MSI and does not allow the application to open.

Is there some way to get the merge module to always overwrite?

Answer 1

This sounds suspiciously like this bug:

http://support.microsoft.com/kb/905238/en-us

and I've come across this bug and you do see that log message, and RemoveExistingProducts is early in the install. It decides to not install the file based on the higher version being there, but doesn't re-evaluate that decision after the REP removes it. Then a repair restores it when you use a shortcut. The bug should apply only to files in the GAC or SxS, so that's a bit puzzling.

If you can schedule REP at the end of the transaction sequence (InstallExecute, REP, InstallFinalize) that should fix it - might be worth a try, all other effects of the move being ok.

Answer 2

Merge modules don't get installed, they get merged. Product MSI's get installed. One of the problems with using third party merge modules is if they have a bug, there isn't much you can do about it.

I'd consider creating an MSI solely for the purpose of encapsulating this MSM. Then I'd create a setup prereq or suite installer to install this MSI apart from your product MSI.

Answer 3

You have got two really good answers already, but to try and synthesize:

It really sounds like a buggy merge module. Phil suggests to fix your REP placement in the InstallExecuteSequence to work around the bug. Chris suggests to put the faulty merge module in its own setup. I agree with both and think you should follow both suggestions:

• Remove the merge module from your main setup.
• Create a new setup and add the faulty merge module and ensure the right REP sequencing.

For the REP fix to work your component referencing must be 100% correct - now and in the future. To eliminate this as a problem creating a separate setup allows you to contain the buggy module inside its own MSI. This will help you avoid re-activating the bug by mistake or by changed design in the future - and the latter is never unlikely.

As Chris says: a merge module isn't delivered, it is merged. An updated merge module may be available for all I know, but even then it is wise to contain it. Especially when you are dealing with the GAC (Global Assembly Cache).

Answer 4

Another solution that I applied when encountered this bug was to set to update the "Version" column from File table, in the merge module, using Orca. Set that to the maximum 65535.65535.65535.65535, this will force the upgrade to always install the DLL from the merge module.