Self-Registration vs. Registry tables group

COM Servers are every Setup developer's nightmare. One of my friends, a release engineer, expressed her extreme frustration over the technique that they had used to register COM Servers. The setup developer had written 100s of lines of code to launch RegSvr32 using the '/s' switch to register these COM Servers. In theory, the process of registration of a COM Server is perfectly fine when done via the regsvr32 utility. But there are certain disadvantages while doing that from the MSI Engineer's perspective. Firstly, all the dependencies of the server need to be registered in a specific order. And secondly, the user performing the installation should have administrative rights. The latter aspect makes setup developers and administrators loathe the registration process.

Further, system administrators do not know the registry settings and COM interfaces that are exposed by the COM object. COM objects do not support reflection and hence are essentially black boxes. Windows Installer has a 'SelfReg' table which can be used to self-register COM servers. There are several disadvantages while using this table.

• Order of registration cannot be specified. Thus if the DLL has dependencies and the dependencies are not registered already, the self-registration would fail.


• Rollback cannot be done reliably


• Self-Registration requires administrative privileges


• You cannot exploit the install-on-demand features of Windows Installer


• You cannot register EXE (Out of process) servers.
  

Tools like InstallShield X provide alternative methods to perform self-registration. This works around certain limitations like specifying the order of registration and registering EXE files. But largely there are limitations that are not in sync with Windows Installer's philosophy of a setup. Speaking of Setup Philosophy, RobMen's blog on his philosophical musings is really worth a read. I personally consider performing self-registration a fiendish act. Microsoft does not absolutely recommend it. Instead it recommends the use of Registry Table group. These are a set of tables like Class, ProgId, Typelib, MIME, Extension and so forth that can be used to store COM information. Most of this information should be available in the generated IDL file for the COM component. If you have any trouble figuring it out, you can peep into the registry during the registration process using various registry-spying tools and extract the appropriate information. Thankfully, tools like InstallShield X abstract this process. For example, using InstallShield X you can extract COM information from the key file of the component during the build time by setting the "COM Extract at Build" attribute of the component in the InstallShield X IDE. Although this makes life easy for a lot of setup developers, this technique has its share of pains. Although not perfect, this technique would solve most of the issues related with COM Registration.

InstallShield also provides a simple utility call RegSpyUI.exe that helps users look at COM information for a specific DLL or exe. This tool is undocumented, unsupported and hence I do not know all the bad things that it might do. But it is a really cool utility, which helps us work around such nasty limitations. Search the InstallShield X or DevStudio installation directory for this tool. There are a few references to this tool in the InstallShield Communities. So if something bad happens to your computer, don’t blame me. You have been warned.

Some of the motivating factors for authoring these tables as opposed to self-registration are:

1. You can forget about dependencies. Since all the information is already authored in the table, you do not need the COM servers registered in order.


2. You can register all kinds of COM Components (DLL, EXE, OCX and the like.)


3. You do not need administrative privileges. Since the registration is carried out by the standard actions, you can exploit MSI's support for elevated privileges. This is a boon for people handling locked down environments.


4. You can now support Installation-on-Demand for these COM Components. I would cover this in detail some other day.

With all these facts by your side, I am now sure that you can convince any setup developer to use the Registry Table Group instead of performing self-registration.