Want to know the criteria for creation of merge modules i.e. how to decide when to create the merge module for a file and when to not....

If thr is some specific document\white paper related to this please share it.

0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity



I asked the same question, and this answer helped me.
Hope that'll be the same for you.

Look at this too :

Although I've mentioned Windows Installer components a lot, VS's IDE doesn't expose the idea of components. When you build a package it creates a component for each file, but you don't get a component view into the package being built. However, because sharing is something that happens at the component level, developers need some way to build shareable components instead of simply replicating all the settings for a shared component over and over again into a collection of packages. The package of reusable components that is designed to be shared by multiple products is called a Merge Module. A Merge Module is practically identical to an MSI package, and you can open Merge Modules and edit them with Orca. However, they have an MSM file extension and usually contain just installer components—they have no user interface if they are designed to contain only shared files. A Merge Module is designed to be merged into an installer package at build time as a subpackage of predefined installation components, and once a Merge Module has been merged into an actual installation database package it loses its separate identity. The contents of the module's database tables, such as the File table, Class table, ProgId table, and so on are merged so that the resulting package has single copies of all the tables.

(© Phil Wilson - The definitive guide to windows installer)
Answered 07/29/2005 by: babric
Senior Purple Belt

Please log in to comment