About Merge Modules

Merge Modules are a highlighted feature of Windows Installer technology. 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 are simplified MSI files, pre-compiled bundles of components (files, registry changes, and other modules) that enable you to easily add third party features to your installation.

An example of this would be the Crystal Merge Module - there were three files that all belonged together. Each time the files are needed instead of putting them in one by one, build a merge module for all three. Each time the merge module is added to an .msi or a .wsi, the three files and all the information (E.g. Registry keys etc) that go with the files are added.

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.

Wise for Windows Installer ships with already created merge modules, which install commonly used Microsoft software packages such as MDAC, ActiveX controls, MFC, and DCOM. A merge module cannot be installed alone. It must be merged into an installation package (MSI) with a merge tool.

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.

When to make merge modules:

• When an application installation is packaged, the files contained in the installation will be found during an install capture.
  It is then necessary to separate files:
• Used only by the application
• 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:
1. WINDOWS\System32
2. WINDOWS\System
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:
• Normally any component that an application setup installs to a shared directory is a shared component. Even if unregistered.
• 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)

DLL + dependent DLL’s

File suites where it is not clear exactly which files are used. In this case the safest thing to do is to include all (E.g. Crystal Reports Runtime).

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 (E.g. VB4 Runtime).

Versions of Files

When you have two identical files and you are not sure which one to use. Check the version of each file and use the file with the higher version. However if the difference between versions is minor use the older version if it works with the application. Only when there is a significant change in the version number should the higher version of the file be used.

Where are they used and what are the Advantages

• The primary reason for using merge modules is to put together a package that other groups can use in their installations.
• If a piece of functionality is likely to be reused within multiple products it should be set up in it’s own merge module.
• Merge modules contain all the information required in a single file.
• They can save the user from having to individually install the same files, registry entries and other components to several installations.
• This helps prevent potential problems, which could be encountered when manually installing files, registry entries, etc. In doing so merge modules provide re-usable code thus reducing TCO (total cost of ownership).
• For example, suppose you have many applications that require the same version of Visual Basic runtime. Well, instead of individually adding the files, registry entries, etc., to each of your installations, you can create a merge module that installs and configures the Visual Basic runtime, and then you simply add this merge module to each application package.
• When we need to update the configuration of the Visual Basic runtime, instead of updating all the installation packages, we simply update the merge module and then recompile the packages containing that module.

When not to make Merge Modules.

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

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

Merge Modules - Their Relationship to MSI Files

A merge module has the same basic format as an MSI file containing a relational database and a summary information stream, only a merge module contains no features. It has a MSM extension. The module itself is assigned a GUID (Globally Unique Identifier) and keys for every row in every table are assigned the same GUID.

• A merge module represents what can be placed under a single feature in an installation.
• 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.

Steps in Building a Merge Module

Merge modules cannot have multiple features (obviously merge modules can belong to multiple features, and where this occurs the module should be added to all of them).

• Open Wise for Windows Installer
• To capture all files, shortcuts, registry entries, etc. we will use a 3rd Party Tool e.g InstallRite
• Copy InstallRite exe from server onto Desktop and install on C:\
• During Install the following dialog appears - “Setup Complete” Dialog - untick both options
• Place InstallRite in the Startup Folder

Then select Finish - launch application

In case the dll is already there - Unregister dll to take out all registry information

• To unregister - run the following from command line in DOS
  regsvr32 /u drag in specific dll (e.g. c:\Windows\System32\Regwizc.dll)
  (Dialog Prompt will confirm successful uninstall)
• Go into InstallRite -
• Select 1st option “Install new software and create an Install Kit”- to start initial capture
• Select Configure - untick Scan all drives, select Next, Next
  In Dialog “Registry Monitor” unselect All and highlight Classes Root
  Select Finish
• To Start initial scan Select Next, Next, Next
• Starts scanning (1st capture)
• When Dialog “choose the installation program to run” appears you must register dll as Dll must be in it’s install location e.g. System 32
• To Register dll - Go to cmd line enter regsvr32 followed by name of dll
• Return to InstallRite - run second part of capture
• Give it a name e.g. name (do not include .dll extension)
• Select Finish
• Select Second option “Review installation”
• Select name of dll on left
• Select Registry - Added Registry - Classes Root (ignore all other Roots)

To export registry information:

• Right click Export Registry to desktop
  In Wise:
  Choose File New - Other Templates - Merge Module.
• On the same dialog box there are two options at the bottom. Choose the “Create .WSI or .WSM project file….” Option on the New Installation File Dialog.
• In Blank Merge Module - add dll files
• Locate dll C:\Windows\System32\Regwizc.dll
• Drag it into project into same folder structure e.g. C:\Windows\System32
• Select Registry Page
• Import Reg file - right click and import
  Import reg file - choose No
• Setup Editor - Components (you are left with 2 components)
• Drag reg info into the component with files and delete other empty component
• Save WSM

Turn on reference counting - right click on component and go to details – check ‘Always increment shared dll count”.

• Fill out “General Information” Page, Title, etc
• Right click on dll which you have installed on machine
  Select Properties - Module name (customer specifies),

Version

copy version and paste into “Module Details” Page e.g. Module Name DAO35.DLL.3.51.10270

To validate a Merge Module

Completed merge modules can be tested or validated using MERGEMOD.CUB.

This is a Microsoft tool that runs a merge module consistency checks test. MERGEMOD.CUB is located in the Wise for Windows Installer directory.

To validate your merge module 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’

Other Method use ORCA to validate or You can use WISE Package studio's Package Validation.

Merge Module Errors

Most common error for Merge Module is missing validation table.

EXAMPLE

ICE Error ICE03 – Setup Editor – Tables – Validation Table

Make entry in Validation Table it will solve your problem.

Final CheckList

1. Check for hard coded paths.
• Click on the Setup Editor tab.
• Click on the top table then on the top menu click on Edit, then Find ( detailed below…) .
• The search dialog box appears. Type in any hard coded paths that you think the registry might hold: E.g. D:\ C:\ X:\.
• If you find a hard coded path in your registry eg. c:\winnt\system32\Dbmsshrn.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:\winnt\system32 and add in the following [SystemFolder]Dbmsshrn.dll.
2. Search for the following and if they appear, delete them, as they are not supposed to be in the registry.

Examples of what to search for:

• Name of server.e.g. \\ABCD
• Your name (eg. Harsh)
• Your script machine name (eg. ABCDSCRIPT)
• any other name that might refer to you or your machine.

Compile WSM

Choose Compile and when prompted save the Merge Module as a.wsm file in the previously created directory with an appropriate file name (on d:\ drive). Usually the name of the file eg HTML WH.DLL, the merge module would be called: HTML WH.

The MergeModule creation method varies but above here I tried to compile best practices. Try to search it on Internet, if you are able to find a vendor created MergeModule then directly use it with the application. Else follow the standards to create the Merge Module.