Global MSI Software

A merge module is a group of resources that are associated together as a functional part of an application or feature within an application. They have the same basic format as an MSI file containing a relational database and a summary information stream; only a merge module will contain no features as it is a single feature in its own right.
It has a MSM extension and the module itself is assigned a GUID and keys for every row in every table are assigned the same GUID.

A merge module consists of the following parts:

	A merge module database containing the installation properties and setup logic being delivered by the merge module.
	A merge module summary information stream describing the module.
	A merge module cabinet file stored as a stream inside the merge module. This cabinet contains all the files required by the components delivered by the merge module.

The ability to create merge modules is a feature provided by the Windows Installer MSI technology which 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 are simplified MSI files, simply they are pre-compiled reusable bundles of components, files, registry changes, and other modules, that enable you to easily add third party features to your installation.

For example if you have a group of files and registry keys that work together and are dependant on each other then create a merge module. Each time the files are needed instead of putting them in one by one, build a merge module for all of them. Each time the merge module is added to an .msi or a .wsi all of the files and information that go with the files are added.

These 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.

Most mainstream packaging tools already ship with pre created merge modules, which install commonly, used Microsoft software packages such as MDAC, ActiveX controls etc.
There are a lot of other third party companies that have created their own MSM files and these can be used with caution once functionality has been tested with the correct validation.

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.

The following procedure describes the general steps to authoring merge modules.

This was taken from msdn.microsoft.com™® on a generic creation for merge modules.

1. Obtain a software tool you can use to edit the merge module database.
2. Obtain a blank merge module database.
3. Generate a GUID for the merge module. You need to use this GUID when authoring the primary keys of database tables in the merge module.
4. Add a record to the Component table for each component delivered by the merge. A Component table is required in every merge module. Note that merge modules operate with components and not with features. In certain cases, however, a database table entry may need to reference a feature.
5. Add a Directory table to the merge module that specifies the layout of directories the merge module adds to the target database. A Directory table is required in every merge module.
6. Import a blank FeatureComponents into the merge module database. This empty table provides a guideline for the merge tool in cases where the .msi file does not contain its own FeatureComponents table.
7. Collect all the files delivered by this merge module and create the MergeModule.CABinet cabinet file. Add the cabinet to the merge module as a stream inside the .msm file.
8. Add a record to the File table for every file stored in MergeModule.CABinet.
9. Add the information necessary to identify the merge module in the ModuleSignature table. Every merge module requires a ModuleSignature table.
10. List the components in the merge module in the Module Components table. Every merge module requires a ModuleComponents table.
11. Add merge module sequence tables to the .msm file only if the merge module needs to modify the sequence tables of the target installation database.
12. Add a _Validation table to the merge module. A merge module requires a _Validation table to pass validation.
13. Merge modules require a user interface in only rare cases. Including a UI with a merge module is not recommended. In cases where a user interface is required, the UI tables can be merged into the .msi file the same as other tables.
14. Add registry information to the appropriate registry tables in the merge module database. Add registry information for type libraries, classes, extensions, and verbs into the TypeLib, Class, AppId, ProgId, Extension, Verb, or MIME tables. All other registry information can go into the Registry table. The use of the SelfReg table is not recommended.
15. Add the summary information to the Merge Module Summary Information Stream.
16. Run validation on all merge modules before attempting to install.

The following described the best practices for creation of merge modules using the Wise for Packaging Studio:-

1. Open Windows Installer Editor.
2. Go to File > New > Other Templates and choose Merge Module.
3. Have the file or files installed and registered on your base PC, and with Install editor open navigate to the file right click and get the properties open.


From this all the information needed to label the MSM file correctly is available to copy and paste into your project.


4. The information needed to be added to the project is file version, product name, original file name, and description.
5. Once this has been added to the project, then within Installation Expert go to the files tab.
6. Drag and drop the file in from the base PC into the correct place e.g. Destination Computer\Windows\System32.


Dragging and dropping from the target PC into your project will pull all the CLSID information needed to accompany the file for registration.


7. Finally save and compile your MSM project ready for testing and validation then use in your environment.

	Simple rules that will ensure applications do not break other applications
	The primary reason for using merge modules is to create self contained package that other groups can use in their installations when merged in.
	If a piece of functionality is likely to be reused within multiple products it should be set up in its own merge module.
	It can save the user from having to individually install the same files, registry entries and other components to several installations.
	When we need to update the configuration of a runtime component, instead of updating all the installation packages, the merge module can be simply updated and then added to the original package by recompiling, thus saving time and effort creating a new package.

	Consistency
	Easier troubleshooting
	Less re-work

A component should not be made into a merge module if:

	The application installs the file into its own directory.
	Files from the protected DLLCache should not be included merge modules or in any msi package for that matter.

To validate a merge module can be done in Orca using the merge module validation suite. Before this was an available feature within Orca, MSM files would need to be validated against the MergeMod.Cub which ships with most mainstream packaging tools.

To validate your merge module you would have to follow this procedure.
Open the command window
Drag in MsiVal2.exe, press the space bar
Drag in your Merge Module, press the space bar
Drag in MergeMod.Cub
Print the results to a text file '>> MyFile.txt'


Most common errors for Merge Module are missing validation table (See ICE error resolution on our site)


The final checks can be done in Orca and edited accordingly.

	Check for hard coded paths.
	If you find a hard coded path in your registry e.g. c:\windows\system32\MyAppFile.dll. The best process to follow is to select the Directory table. Copy SystemFolder out of the Directory column. Go down to the Registry table and delete c:\windows\system32 and add in the following [$SystemFolder] MyAppFile.dll.