Self-Registration

The most common way to create whatever registry entries you need is to ship a REG file with your component. However, there is always the risk that a component server might show up on a system without any such registry file and without an installation program that knows what entries to create. When a system contains potentially thousands of components, dragging around registry files and installation programs for each of them becomes highly inconvenient. For that reason, COM defines a self-registration mechanism that enables you to encapsulate registry needs into a DLL or an EXE. This provides clients, as well as future system shells, with an easy way to be sure that any given module is fully and accurately registered. In addition, COM also includes a mechanism so that a server can remove (unregister) all of its registry entries when the DLL or EXE is removed from the file system, thereby keeping the registry clean of useless trash.

Self-registration is considered optional for many components, but it is strongly encouraged for exactly the reasons stated above. When a server does support this feature, it can indicate its support in its version information resource by including an entry "OLESelfRegister" with an empty value in the "StringFileInfo" section of the version resource:

VS_VERSION_INFO VERSIONINFO
 [...]
 BEGIN
   BLOCK "StringFileInfo"
    BEGIN
     BLOCK "040904B0" // Lang=US English, CharSet=Unicode
      BEGIN
       [...]
       VALUE "OLESelfRegister", "\0"
      END
   END
 [...]
 END

This entry is optional because the actual self-registration mechanisms do not depend on it. The information simply allows a caller to avoid loading a DLL or launching an EXE for no gain.

When asked to self-register, a server must create all entries for every component that it supports, including any entries for type libraries. When asked to unregister, the server must remove the entries that it created in its self-registration. For a DLL server, these requests are made through calls to the exported functions DllRegisterServer and DllUnregisterServer, which must exist in the DLL under these exact names. Both functions take no arguments and return an HRESULT to indicate the result. The two applicable error codes are SELFREG_E_CLASS (failure to register/unregister CLSID information) and SELFREG_E_TYPELIB (failure to register/unregister type library information).1 Because exported functions cannot be used from an EXE, a local server must instead watch for two command-line arguments passed to its WinMain named /RegServer and /UnregServer (case-insensitive, they may also appear as -RegServer and -UnregServer). If either argument is detected, the server must perform the necessary registration or unregistration and immediately terminate, without ever showing a main window or executing other code.