COM in the Windows Installer World - Installing a COM Server
(Page 2 of 7 )
In Chapter 1 I talked about the transactional nature of an installation and minimizing the code that runs during an installation. If the registration of a COM server isn’t going to call DllRegisterServer, how does the registration code get written to the Registry? A Windows Installer package does contain tables pertaining to COM registration, the contents of which get written to the Registry at install time. That begs the question of how you get the data into the tables in the first place. The answer to that depends on what tool you use to build your installation package. Some tools can spy on the progress of DllRegisterServer and populate the tables for you. If your tool doesn’t, a helper program is supplied with the book to let you see the Registry entries.
In this case, you’re using VS, and you’ll install a COM DLL that’s supplied with the book. Use VS to start a new Setup and Deployment project, as with the Notepad installation in Chapter 2. This time the only file you’ll be adding to the Application folder is the COM DLL from the COMServer project sample. This COMServer project has been altered so it does not do automatic self-registration of the DLL when it compiles. By default the VS development environment for a COM server generates a call to REGSVR32.EXE to register the server, but this postbuild step has been removed from the project to keep registration data off the system until installation time.
As in Chapter 2’s Notepad installation, you can create a new Setup and Deployment project and get to the point where you’re adding files to the target system. If you add COMServer.dll and look at its properties, you’ll see the screen in Figure 3-1.
Figure 3-1. COM server properties
Under the Register property, VS has set the default to vsdrfCOMSelfReg, the setting to self-register the DLL by calling DllRegisterServer. Aside from wondering why this should be the default for a Windows Installer project, how did it know this is a COM server? VS looked at the version resources for the DLL and found an OLESelfRegister setting. This is a standard marker for self-registering servers. But in the choices for the Register property, there is another choice: the vsdrfCOM value. Selecting this causes VS to extract the COM registration entries when you build the setup project, and it populates the appropriate tables. After building the package, run Orca on it and look at the Class table that contains the COM class information (see Figure 3-2).
Figure 3-2. The Class table
As you can see, a CLSID column contains a CLSID that the COM server supplies. The Context column shows it to be an InprocServer32 COM server (as opposed to LocalServer32 for an out-of-process server). The default ProgId for the class is there, and so is the Windows Installer component that this COM server is associated with. (At the risk of stating the obvious, this extraction process that VS performed still uses the DllRegisterServer call and monitors what happens. This means that the DLL itself requires its dependent DLLs to load when you build the Setup project, so they need to be present on the development machine. You can verify this behavior by putting a MessageBox call in the DllRegisterServer code. You’ll see that it gets called during VS’s build process.)
Note the SharedLegacyFile property that appers in Figure 3-1. This setting maps to the SharedDLLs reference counting in the Registry through the msidbComponentAttributesSharedDllRefCount in the Component table of the package. Setting this bit forces creation of a SharedDLLs entry in the Registry, but if you don’t set it and Windows Installer finds an existing entry, Windows Installer increments the existing count for the SharedDLLs entry. You can always set this property to True for an installation. It does no harm, and the file won’t get removed accidentally if some other non-Windows Installer setup installs the file to the same location and uses the SharedDLLs references.
Although this Orca view in Figure 3-2 is truncated, there is in fact no direct reference to the DLL you’re installing—this linkage is indirect, through the Component entry in the Class table. The Component table for this component has a KeyPath entry, and this KeyPath entry is in turn a key that refers to the File table entry for the server. This is another example of the Windows Installer design principle described in Chapter 2, where the Shortcut table has a Component entry with a KeyPath entry referring to a target file.
There is more to COM registration than just the CLSID entries. Figure 3-3 shows the entries for the COM ProgID, showing the version-independent ProgID and the specific versioned ProgID. The version-independent one has a parent linkage to the versioned entry.
Figure 3-3. The ProgId table
There is also a TypeLib table, which contains the basic type library entry. Again, the Component_ column is a key to the Component table, where the KeyPath column refers to the File table entry for the type library. At install time, Windows Installer registers the type library (the same functionality as the Win32 RegisterTypeLib API). Remember that in this case the type library is embedded in the resources section of the code file.
 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: Type Libraries >>
More Windows Scripting Articles
More By Apress Publishing
