SelfReg Entries and Their Significance in an MSI

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.

Steps to follow when a package contains a SelfReg entry.

Whenever SelfReg entries are there in the package, you should do the following:

1. Look for WiseComcapture.exe in %ProgramFiles%\Wise Package Studio\Windows Installer Editor\, as shown in Fig 1.
   
   

   Figure 1

   Click to view.

2. On double clicking this exe, you will understand the command. See Fig. 2
   
   

   Figure 2

   Click to view.

3. Install the application source/Copy that file to the respective physical location. Ex: if the selfreg having a reference for "Comdlg32.ocx", then locate the component "Comdlg32.ocx" and note down the path where it is getting installed, say "C:\Windows\System32". See Fig 3
   
   

   Figure 3

   Click to view.

4. Now use "WiseComCapture" to get the registry entries as follows:
   

   WiseComCapture.exe /r "C:\Windows\System32\Comdlg32.ocx"
   C:\Comdlg32.reg.
   
   

   

   Figure 4

   Click to view.

5. Now "Comdlg32.reg" will have the registries which are associated with Comdlg32.ocx See Fig.5 and 6
   
   

   Figure 5

   Click to view.

   

   Figure 6

   Click to view.

6. Now delete the registry entries from "Class" table, "ProgID" Table, "Registry" table, which is associated with "Comdlg32.ocx" Component in the package. And also delete the "Comdlg32.ocx" entry in the selfreg table.
7. Locate "Comdlg32.ocx" component and import the registry "Comdlg32.reg", say "NO" (Or yes, if it is required) when prompted for advertisement. See Fig 7 and 8.
   
   

   Figure 7

   Click to view.

   

   Figure 8

   Click to view.

8. Continue all the above steps for other selfReg entries.

Why shouldn't a package contain a SelfReg entry?

The package should not contain any selfreg entries because:

• 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.