- Merge modules are a mechanism in Windows Installer that allows software companies to repackage and share standard component definitions.It enables the encapsulation of a component or set of related components and their resources, and the subsequent merging of this module with install packages which require the component or component-set.
- Merge modules cannot be run separately and are used to add information to an installation package at compile time. After the merge is complete all the information in the merge module is incorporated into the MSI.
- Merge modules contain tables not found in an MSI and a couple of these tables such as ModuleSignature and ModuleComponents are Required. These tables list the information identifying the merge module and the components included in the merge module respectively.For a full list of the tables unique to merge modules refer to the Windows Installer SDK under the topic Merge Module Database Tables.
o Used only by the application
o Those that are Shared Components.
• Shared Components are files which are used by other applications. Such files are: .DLL, .OCX, .TLB, .OLB, .EXE and other support files as required (e.g.HLP).
These files are usually files that install to:
3. Program Files\Common Files\
or Program Files\Common Files\System\
or Program Files\Common Files\Shared\
or Program Files\Application Folder\Shared\
• Both 16-bit and 32-bit components installed in a shared directory should normally be considered shared.
• Both registered and unregistered components installed in a shared directory should normally be considered shared:
o Normally any component that an application setup installs to a shared directory is a shared component. Even if unregistered.
o An unregistered shared component can be moved to the application directory. It then must be checked if the application works with it or not.
Sometimes it is possible that a setup may install a component to a shared directory, but it is really not shared. The first thing to do is to check the vendor name of the DLL/OCX in the shared directory if unsure.
• If the vendor name is different from the other vendor names of the files in the shared directory then try to put it in the application directory. This should only be done if the packager is sure that the application function will not be jeopardized by this change.
• Different applications provided by the same vendor may use some shared components the application vendor created. In this case such components should be considered as being shared, since they are shared between applications provided by the same application vendor
Encapsulate files as much as possible.
If a set of files go together, they should be created as a Merge Module. Merge Modules can contain other Merge Modules in a hierarchical way, so this technique can be used where Merge Modules are dependent on other Merge Modules.
The following cases indicate where this should be done:
OCX + dependent files (DLL’s, TLB’s, HLP’s etc)
File suites where it is not clear exactly which files are used. In this case the safest thing to do is to include all For simplicity. Although it is always possible to create a Merge Module for each file, it is not necessary, since this would include adding a lot of Merge Modules to a package rather than one.
• The application installs the file into it’s own directory.
• Files found in WINDOWS\System32\Dllcache are used for Windows File Protection.Also files found in this location should not be in any package.