Merge modules - what are they good for?
I've been roaming this site for postings regarding Merge modules, and the purpose of ... while i was reading " What should I use ? Merge modules or Not ?" i'm still not quite satisfied in my quest of understanding why i would use these pesky things
My experience with merge modules:
1) While snapping an application, Wise will suggest to add Merge modules instead of files, if my setup capture contains files which are also in a Merge module
2) If i do so, i have no way of going back (in case of DLL conflicting or other reason, ie. how do you isolate a merge module?) - So I rather take the "safe" way and NOT including Merge modules in my Snapping process, and adding them later instead.
3) If I - once i have finished my snapshot process - add a Merge module, it doesn't automatically remove files and reg keys from my capture which now are dublicates.
4) I can remove a file in Installation Expert and add it again - this way i trigger Wise to suggest a Merge module instead - BUT with same result, it doesn't remove already existing files and reg keys in my package, and again I have dublicate files and keys.
5) Files, ie. DLL's should be treated the same way being in a Merge module or as a Component, ie. if the DLL/Reg key path alerady exists, the files and keys in the component will not be installed, which i think fails to be the case. It will in my experience just add the missing keys
My conclusion: You can't use Merge modules as a way of deconflicting your package, if your package will install system files already existing on your target machines, (ie. rules of DLL's overwriting older versions) leave out merge modules, and deconflict your package by isolation
Anyone?
My experience with merge modules:
1) While snapping an application, Wise will suggest to add Merge modules instead of files, if my setup capture contains files which are also in a Merge module
2) If i do so, i have no way of going back (in case of DLL conflicting or other reason, ie. how do you isolate a merge module?) - So I rather take the "safe" way and NOT including Merge modules in my Snapping process, and adding them later instead.
3) If I - once i have finished my snapshot process - add a Merge module, it doesn't automatically remove files and reg keys from my capture which now are dublicates.
4) I can remove a file in Installation Expert and add it again - this way i trigger Wise to suggest a Merge module instead - BUT with same result, it doesn't remove already existing files and reg keys in my package, and again I have dublicate files and keys.
5) Files, ie. DLL's should be treated the same way being in a Merge module or as a Component, ie. if the DLL/Reg key path alerady exists, the files and keys in the component will not be installed, which i think fails to be the case. It will in my experience just add the missing keys
My conclusion: You can't use Merge modules as a way of deconflicting your package, if your package will install system files already existing on your target machines, (ie. rules of DLL's overwriting older versions) leave out merge modules, and deconflict your package by isolation
Anyone?
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
jonasm
18 years ago
Hi!
As far I know, the point with Merge Modules is that every installation sets that it uses a certain Merge Module. When ALL packages using the Merge Module is removed from the computer, the MSI-engine knows that it´s safe to delete the Merge Modul files as well.
/Jonas
As far I know, the point with Merge Modules is that every installation sets that it uses a certain Merge Module. When ALL packages using the Merge Module is removed from the computer, the MSI-engine knows that it´s safe to delete the Merge Modul files as well.
/Jonas
Posted by:
sikkert
18 years ago
When I read this post, I get the impression that you aren't quite sure about what components and merge modules really are. I think you should read these blogs about component rules, as they explain the problems around using components, and how merge modules are meant to solve this:
http://blogs.msdn.com/robmen/archive/2003/10/04/56479.aspx
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx
As for your questions:
If you need a different version, you should try to get hold of a different merge module. ONLY the creator of a merge module should alter it and give out new versions. If you change a merge module yourself, you go against the whole consept.
I have this problem too, at least in Wise Package Studio 5.6. Hope this is fixed soon (or is it, in version 6?)
A merge module is nothing but a collection of components, so the will be treated the same way. But I have also seen cases where the keypath exists, but other files/registry entries of the component is still installed. Yes, I have verifyed the version of the keypath, and tried a lot of scenarios, but never found an explanation to this.
Since merge modules is just a collection of components, then this is somewhat true. You either need to get a merge module that matches your already installed files, or as you say, use isolation to solve the problem.
http://blogs.msdn.com/robmen/archive/2003/10/04/56479.aspx
http://blogs.msdn.com/robmen/archive/2003/10/18/56497.aspx
As for your questions:
1) While snapping an application, Wise will suggest to add Merge modules instead of files, if my setup capture contains files which are also in a Merge module
2) If i do so, i have no way of going back (in case of DLL conflicting or other reason, ie. how do you isolate a merge module?) - So I rather take the "safe" way and NOT including Merge modules in my Snapping process, and adding them later instead.
If you need a different version, you should try to get hold of a different merge module. ONLY the creator of a merge module should alter it and give out new versions. If you change a merge module yourself, you go against the whole consept.
3) If I - once i have finished my snapshot process - add a Merge module, it doesn't automatically remove files and reg keys from my capture which now are dublicates.
4) I can remove a file in Installation Expert and add it again - this way i trigger Wise to suggest a Merge module instead - BUT with same result, it doesn't remove already existing files and reg keys in my package, and again I have dublicate files and keys.
I have this problem too, at least in Wise Package Studio 5.6. Hope this is fixed soon (or is it, in version 6?)
5) Files, ie. DLL's should be treated the same way being in a Merge module or as a Component, ie. if the DLL/Reg key path alerady exists, the files and keys in the component will not be installed, which i think fails to be the case. It will in my experience just add the missing keys
A merge module is nothing but a collection of components, so the will be treated the same way. But I have also seen cases where the keypath exists, but other files/registry entries of the component is still installed. Yes, I have verifyed the version of the keypath, and tried a lot of scenarios, but never found an explanation to this.
My conclusion: You can't use Merge modules as a way of deconflicting your package, if your package will install system files already existing on your target machines, (ie. rules of DLL's overwriting older versions) leave out merge modules, and deconflict your package by isolation
Since merge modules is just a collection of components, then this is somewhat true. You either need to get a merge module that matches your already installed files, or as you say, use isolation to solve the problem.
Posted by:
brenthunter2005
18 years ago
Merge Modules keeps the component GUIDs the same across your installation base, and therefore are less prone to conflicts within Windows Installer itself.
I do attempt to isolate shared DLLs where possible, and if not, then include the standard Merge Modules.
I do attempt to isolate shared DLLs where possible, and if not, then include the standard Merge Modules.
Posted by:
norexx
18 years ago
My conclusion: You can't use Merge modules as a way of deconflicting your package, if your package will install system files already existing on your target machines, (ie. rules of DLL's overwriting older versions) leave out merge modules, and deconflict your package by isolation
Have to disagree 100% with this statement. Merge modules ARE a good way to "deconflict" your package, in that you are ensuring a consistent set of DLLs, OCXs & associated regkeys across all packages within your organization. Isolation is fine for modestly sized packages and when you have relatively small numbers of applications to isolate, but is so time-consuming for large apps (> 100MB) as to be essentially useless. I have also found that it tends to break large complex applications with lots of dependencies.
This is also true of importing large apps into Conflict Manager. The bigger the app and the more apps in your catalog that you have to run it against, the longer it takes. The firm I work for is very large and has a huge catalog of re-packaged customized MSIs (1300+). It literally takes 12+ hours to run Conflict Manager in Wise Studio 5.6, with end result usually being it bombs before completing.
Merge modules represent one of the easiest, fastest most reliable ways to deconflict your packages. Now if only Wise would update their merge modules more often. Most of them are woefully out of date.
Posted by:
kkaminsk
18 years ago
Merge modules are a great concept but the implementation has something to be desired. With common DLLs from Microsoft you can usually get great merge modules but look at Crystal Reports for example. Everybody and thier dog seems to have their own merge modules for Crystal Reports and not to mention that some of them don't work so well. I believe merge modules would be great if there was a body that certified and maintained a known good set of merge modules. So my general rule of thumb is to use the merge modules supplied by Microsoft then use Vendor specific merge modules if the vendor publishes them. I tend to stay away from third party modules because you really never know how well they were built but then again vendors have been known to have flaws with their own modules as well. I have questioned using merge modules myself but I try to use them because that is ideally the way you should be doing things.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
