COM in the Windows Installer World - InprocServer32 Entries and Repair
(Page 4 of 7 )
After you install this COM server, if you run a Registry editor and take a look at the CLSID entries you might be somewhat alarmed. In the InprocServer32 key entry there is an InprocServer32 data item, a REG_MULTI_SZ apparently consisting of garbage (see Figure 3-5).
Figure 3-5. The repair descriptor
Occasionally people see this and worry that the installation has corrupted the Registry, but in fact this data—this descriptor—is related to repair. More on this later.
COM Server Dependencies A COM server might have dependencies on other COM servers or DLLs, so clearly you need to install them somewhere that the COM server can find them. They should be installed in the same folder as the COM server. You might find documentation or advice that refers to installing dependent DLLs into the application folder. This usually means the folder where the client program is installed, but in this context “application folder” means the COM server’s folder. This makes a lot of sense. In an object-oriented component world, client programs should be oblivious to the implementation details of the server components, and no client program wants to be in the business of installing a COM server’s dependencies in its application folder.
Windows Installer Sharing I started this chapter by describing the original Windows sharing scheme based on the SharedDLLs Registry data. Windows Installer sometimes uses this mechanism because it must handle the cases where a shared DLL has already been installed (or will be installed later) by some non-Windows Installer method. By default, Windows Installer increments the SharedDLLs reference count for a path if there is an existing entry for it in the Registry. If your product installation requires the Installer to create a new SharedDLLs entry, the msidbComponentAttributesSharedDllRefCount bit must be set in the Attributes data in the Component table. To reiterate: not the File table, the Component table, and as you’ve seen before, this SharedDLLs setting applies to the KeyPath of the component.
The Windows Installer sharing mechanism works at the component level. Each component has a GUID, and Windows Installer counts the uses of this GUID. However, just like the SharedDLLs mechanism, this reference counting is meaningful only when it counts multiple references to a single location. If product P1 installs a component to its own private application folder, and then product P2 installs the same component GUID to a different private application folder, no sharing is effectively going on. Product P1 reference counts the component to its private folder and product P2 does the same. The key point here is that reference counting has no practical effect unless the same physical location of an installer component is shared by multiple separate products. In other words, the behavior of the installer’s sharing mechanism is essentially the same as the SharedDLLs mechanism discussed earlier. Instead of a Registry mechanism where each product install increments a count on a path to a file, the installer uses a GUID to reference count each use of the component. However, it is meaningful for sharing only when the component is installed to the same location by different products.
There’s some simplification in that description, because the key path of a component doesn’t have to be a file—it can be Registry data.
 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: Merge Modules and Sharing >>
More Windows Scripting Articles
More By Apress Publishing
