COM in the Windows Installer World - Merge Modules and Sharing
(Page 5 of 7 )
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.
You just built an installer package to install a COM server, but the proper way to install the COM server so it can be shared properly would be to create a Merge Module and then add it into any other product installation packages that require it.
Building a Merge Module When you start VS’s New Project wizard and choose Setup and Deployment Projects, one of the choices there is for a Merge Module project. If you create a Merge Module project for the COM server using the New Project wizard, you’ll find that the process of creating a Merge Module is nearly identical to the way in which you created the setup project earlier on. If you look at Figure 3-6 you’ll see that the DLL is being installed into the Common Files folder under a specific folder. This makes sure that all users of this COM server install it to a specific location where they can share it.
Figure 3-6. Merge Module destination
You’re also choosing that location because it becomes the standard installation folder for all client setups that include this Merge Module. The other choice of Module Retargetable Folder, as its name implies, is a means whereby client setups get to choose the installation folder for the Merge Module files. You don’t want that choice for your sharable COM server. If you build this project and then look at the File, Component, Class, ProgId, and Registry tables you’ll see that they contain the same registration information as the package you built before.
A Merge Module is of no use unless you can merge it into an installation. If you open up that Notepad installation project, you can incorporate a Merge Module in a couple of ways. If you select the Project name in the Solution Explorer, the right-click menu has an Add choice that goes on to offer a Merge Module choice. Alternatively, the Project menu also offers an Add to allow a Merge Module to be selected. Once you add it, it shows up in the Solution Explorer with the other files. After you’ve built the new Notepad installation package that now incorporates the Merge Module for the COM server, you can open it with Orca and find little trace of the original Merge Module. For example, the Orca view of the File table now contains the DLL from the Merge Module (see Figure 3-7).
Figure 3-7. File table with COM server
Note that the File column entry for the COM server is different from the other files; the File column for COMServer.dll has a two-part name, where the second part after the period does not exist for the files that were not in a Merge Module. The issue here is that the item in the File column must be unique to the File table. A tool that generates the File table directly, such as VS, can guarantee that each entry it generates is unique to that package. However, when a File table is being merged from an external Merge Module there is no such guarantee of unique File column names. To make them unique, VS appends the package code GUID of the Merge Module that is the source of this File table entry.
Because a Merge Module is literally merged into a containing database package, it’s important to realize that there is no sense in which the Merge Module contents are separately installed. The contents of the Merge Module— one or more Windows Installer components—become an integral part of the final package and are installed on the target system in the same way as other components that were created directly in the package.
 This chapter is from The Definitive Guide to Windows Installer by Phil Wilson. (Apress, 2004, ISBN: 1590592972 ). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Relative Paths and Side-by-Side COM Components >>
More Windows Scripting Articles
More By Apress Publishing
