I have a merge module, it contains the binaries for some sort of an engine for some applications. Since it could be shared between apps, I thought it is the right idea to have the engine as a merge module and use the msm in the msi's of the applications that needs the engine.
However, I now think it could be better if I create a separate installer for the engine and separate installers for the applications. And use the chained msi method to install the engine instead of merge modules.
The advantage of chained msi method could be that if there is a new fix or some update for the engine, I could just obtain the installer and run it standalone. But for merge module method, I need to obtain the full installer for the application which has the merge module. In a way, chained msi method would replace merge module approach.
Could you guys let me know what you think on this?
I think it depends largely on what these shared files are. If they are almost an application into their own right, a chained installer makes a lot of sense. If they're just a couple DLLs in a common folder, a merge module may be a better semantic fit. Mind you that if they are truly in a shared location, as opposed to private per-application locations, you'd still be able to update them once with a new full MSI package, although finding out that you needed to might be more difficult than with a known base MSI package.
Finally remember that using chained MSI packages requires Windows Installer 4.5 which is not very widespread yet. Depending on your environment and distribution methods, this may be an important consideration.
Thanks, is there an possibility that Microsoft might depreciate chained msi method? I know it is pretty recent functionality but is there any drawbacks of it?
I cant remember where I heard/read this but I want to make sure if it is a rumor or not.
