COM in the Windows Installer World - Back to Side by Side
(Page 7 of 7 )
The idea of side-by-side COM is simply that each client installs its own private copy of a COM server in its own application folder with two requirements in the DLL case that
- The InProcserver32 path to the COM server is a relative one.
- The application folder contains a clue that the client program requires side-by-side sharing. This clue is in the form of a file with .LOCAL appended to the name of the client program executable.
To implement side-by-side COM with an installer package, you need to look at the IsolatedComponent table. The table itself is uncomplicated; a column called Component_Shared requires the installer Component table row that identifies the COM DLL, and a column called Component_Application that contains the Component table row that identifies the client program executable. In both cases, the KeyPath entry of the component identifies the file. However, there’s more to it than just setting these tables in the installation packages:
- There is clearly no sharing in the side-by-side scenario, so each installation uses its own private copy of the COM server and shouldn’t use a common Merge Module. It’s not that you cannot use a common shared Merge Module here, but if you do, the COM server will have the same installer component GUID associated with multiple products. So if the idea is truly to keep each COM server separate, then keep them separated in every way, including not sharing the same installer component GUID.
- The sharing schemes described earlier (the installer scheme and the SharedDLLs scheme) both have the notion that reference counts to an installation path protect the registration information for the COM server. When an uninstall occurs, these reference counts are decremented, and the last product using the COM server removes the registration entry. There is no such sharing scheme in a side-by-side installation, so an uninstall of a product using side-by-side sharing will potentially remove the COM registration entries unless some other mechanism is used to count the number of products using the COM server. The MSDN article “Implementing Side-by-Side Component Sharing in Applications” (in the Setup section) recommends a Registry item under the InprocServer32 key that is a reference count, incremented at install time and decremented at uninstall time, such that when decremented to zero the registration entries are removed.
- Everyone must agree to the sharing scheme. For example, if the COM server is already installed on the system and the installation program adds an absolute path to the server, you can’t install your copy of the COM server in a side-by-side way.
With these caveats in mind, if you’re going to implement your own side-by-side installation, take a look at the IsolatedComponent table and use it to install the COM server in a side-by-side configuration. You can use the sample projects associated with this chapter. As well as the COMServer project that builds this COM server, a COMClient project builds a C++ executable that calls a method in the COM server. To perform side-by-side installations, you need two setup projects that each install the COMClient program and the COMServer DLL to their own private application folders. These two sample setup projects are named COMClientServerInst and COMClientServerInstAgain. Both were built from scratch and have the same general idea (see Figure 3-8).
Figure 3-8. COM server with relative path
The client executable and the COM DLL are both being installed to the Application Folder, and the COM DLL is using the vsdrfCOMRelativePath choice for Register. VS has no explicit support for side-by-side COM components, which means you need to edit the IsolatedComponent table with Orca. Although the IsolatedComponent table requires Component values, it’s easiest to get those from the File table.
In Figure 3-9 the installer component for the COM DLL and the component for the client executable are in the Component_ column. The Component_ value for the server needs copying to the Component_Shared column of the IsolatedComponent table, and the Component_ value for the client needs copying to the
Component_Application column, so you end up with something like Figure 3-10. Follow this process of modifying the IsolatedComponent table with Orca wherever you are using side-by-side installation for a COM server. In the sample code with this chapter, this means modifying the COMServerInst and the COMServerInstAgain package files.
Figure 3-9. The File table with COM client and server
Figure 3-10. The IsolatedComponent table
If you install one of these packages, you’ll see that Windows Installer has helped out by creating the required .LOCAL file in each application folder, and the Registry entry for the class has the relative path that you’d expect from using the vsdrfCOMRelativePath choice. Installing both of the packages— COMClientServerInst and
COMClientServerInstAgain—also installs shortcuts to their respective client programs. If you use both of the shortcuts, the client programs each display a MessageBox. You can now use a diagnostic program to see what DLLs are loaded into each COMClient.exe (I used the Process Explorer from the Sysinternals Web site at http://www.sysinternals.co). You should see that each separate COMClient.exe is indeed using the COMServer.dll file from its application folder.
Now here’s something cool. If you install a single COM server that has the vsdrfCOMRelativePath option for registration and then uninstall it, you can go to the Registry and notice that the uninstall doesn’t delete all the registration entries for HKCRCLSID{cccxClass GUID}. It leaves some of the entries behind, including the relative path in the InprocServer32 key. Normally you’d consider that to be a bug, but think about the result. If you install both of the sample side-by-side setups and then uninstall one of them, that uninstall should delete all the registration info because that’s what you’d expect from an uninstall. But it doesn’t. What Windows Installer does at install and uninstall is just alter the contents of the InprocServer32 data descriptor that contains an encoding for installer product and component GUIDs. Windows Installer is effectively making side-by-side COM work by keeping those Registry entries present, and altering the content of the InprocServer32 descriptor as other products use the same COM class registration. The cool part about this behavior is the effect it has on other COM clients—those that don’t have their own side-by-side installation. If you run the Callcom.vbs script, the script continues to work when two products are installed, each with its own private side-by-side copy of the COM server. If you uninstall one of these products, that script still continues to work. That’s because, as you saw before when you ran this script, Windows Installer uses the InprocServer32 descriptor to get the installer component’s KeyPath and find the absolute path to the COM server.
In effect Windows Installer can give you all the available options for sharing side-by-side COM servers without having to write any code to do reference counting on the HKCRCLSID{Class GUID} key (as in point 2 in the preceding numbered list), which you’d need to do if you didn’t use Windows Installer. You get side-by-side sharing, you don’t need to build your own reference counting, and Windows Installer finds the latest version of the COM server for other non-side-by-side clients. It does this by finding the path to the server from the Inprocserver32 descriptor and the component KeyPath. When you uninstall the final side-by-side product, the InprocServer32 descriptor disappears as well, so there is no longer any path information anywhere.
Summary You’ve looked at sharing, specifically in the COM context, and drilled down into some of the Installer’s interesting behavior. You saw that Windows Installer uses the descriptor associated with a COM server to locate the actual file, and you used a VBScript to locate an installed file in the same way. Because that descriptor can locate Installer components, it is the mechanism that Windows Installer uses to determine the health of the component and whether it needs repair. As you might guess, the repair that occurs when the target file of a shortcut is missing (see Chapter 2) is triggered by a similar descriptor associated with an advertised shortcut.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
