The SelfReg table contains information about modules that need to be self registered. The installer calls the DllRegisterServer function during installation of the module; it calls DllUnregisterServer during uninstallation of the module. The installer does not self register EXE files.
The SelfReg table has the following columns.
| Column | Type | Key | Nullable |
|---|---|---|---|
| File_ | Identifier | Y | N |
| Cost | Integer | N | Y |
Columns
- File_
External key into the first column of the File table indicating the module that needs to be registered.
- Cost
The cost of registering the module in bytes. This must be a non-negative number.
Remarks
Installation package authors are strongly advised against using self registration. Instead they should register modules by authoring one or more tables provided by the installer for this purpose. For more information, see Registry Tables Group. Many of the benefits of having a central installer service are lost with self registration because self-registration routines tend to hide critical configuration information. Reasons for avoiding self registration include:
- Rollback of an installation with self-registered modules cannot be safely done using DllUnregisterServer because there is no way of telling if the self-registered keys are used by another feature or application.
- The ability to use advertisement is reduced if Class or extension server registration is performed within self-registration routines.
- The installer automatically handles HKCR keys in the registry tables for both per-user or per-machine installations. DllRegisterServer routines currently do not support the notion of a per-user HKCR key.
- If multiple users are using a self-registered application on the same computer, each user must install the application the first time they run it. Otherwise the installer cannot easily determine that the proper HKCU registry keys exist.
- The DllRegisterServer can be denied access to network resources such as type libraries if a component is both specified as run-from-source and is listed in the SelfReg table. This can cause the installation of the component to fail to during an administrative installation.
- Self-registering DLLs are more susceptible to coding errors because the new code required for DllRegisterServer is commonly different for each DLL. Instead use the registry tables in the database to take advantage of existing code provided by the installer.
- Self-registering DLLs can sometimes link to auxiliary DLLs that are not present or are the wrong version. In contrast, the installer can register the DLLs using the registry tables with no dependency on the current state of the system.
Note You cannot specify the order in which the installer registers or unregisters self-registering DLLs by using the SelfRegModules and SelfUnRegModules actions. See Specifying the Order of Self Registration.
Validation
Send comments about this topic to Microsoft
Build date: 8/13/2009
© 2009 Microsoft Corporation. All rights reserved.