Resons for Avoiding Self Registration
Filed under:
Wise Package Studio
Packaging
Submitted by umara on 19 August, 2008 - 16:12.
The following is a list of reasons for not using Self Registration Routines:
- Any activity performed by the self-registration (e.g. addition of registry entries) is out of the control of the Installer, so cannot be part of advertisement, repair and is not removed on uninstall.
- Ability to use advertisement is reduced if class or extension server registration is performed within self-registration routines.
- DllRegisterServer routines currently do not support the notion of a per-user HKCR key. The installer automatically handles HKCR keys in the registry tables for both per-user and per-machine installations.
- 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.
- Unregiteration using selfreg table will just unregister the DLL\OCX even though some other application is using it.
(32 votes)
- Login or register to post comments
- 2725 reads
- Printer-friendly version
Rollback..
Also, the 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 in a vendor MSIs (which contain multiple features).
Cheers'
Vijay
"Wisecomcapture.exe" to avoid self-registration..
To avoid all these issues, we use "wiseComcapture.exe" which is present in %ProgramFiles%\Wise Package Studio\Windows Installer Editor\ for registering a dll.
Step 1:
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".
Step 2:
Now use "WiseComCapture" to get the registry entries as follows:
WiseComCapture.exe /r "C:\Windows\System32\Comdlg32.ocx" C:\Comdlg32.reg.
(Now "Comdlg32.reg" will have the registries which are associated with Comdlg32.ocx )
Step 3:
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.
Step 4:
Locate "Comdlg32.ocx" component and import the registry "Comdlg32.reg" to the component.
This will ensure that, reference count and roll back is achieved for dll registrations.
Cheers'
VIjay
Another way
There are two more ways to do this, but the condition is that the application is installed and the .dll/.ocx is registered on the machine. These may not be fool proof methods, but have worked a lot many times for me. They are worth to give a try since they take in less efforts.
Method 1: You can delete the .dll/.ocx file from Installation expert. If the .dll/.ocx is not registered then you can do so now. Then add the .dll/.ocx in the package from installation expert and the source should be the actual location where you want it to go after the installation of your MSI. This will automatically add the registries in the WSI.
Method 2: Goto the component and do Rescan advertising, it will get in all the registries, associated with it and in proper tables. (I mostly do this for components having advertised information, so not sure for other components. But I think that it should work and is worth a try.)
There are other tools too which can be used to extract registries, but they are not recommended by companies (don't know why... maybe they are too strong to pull out registries :D .). The tool I am talking about is RegSpy. I found it a good tool to extract registries.
Other work around for registering..
There can also be a case when the DLL doesn't exist in the package and there is a necessity to register a file manually.
In such a scenario, we manually register a .DLL using regsvr32.exe in a .MSI package:
Write a Custom action with the following details.
Working Directory: Enter SystemFolder
EXE and Command Line: Enter the full path to regsvr32.exe and the full path to .DLL.
Example: [SystemFolder]regsvr32.exe /s [WindowsFolder]123.DLL
Ensure that the custom action has a condition around it so that it only executes when the installation is getting placed on the computer:
If Not Installed
Execute Program from Destination
End Statement
And another way
It is always a good idea to use them Microsoft WiX (Windows Installer XML) toolkit to find out, what is really during self registration.
For those that do not use Wise and cannot get hold of WiseComCapture, but want to make their installation of COM Servers (ActiveX and others) revertable, even if you have only a "xcopy" deployment, you can use this tool.
Nowadays, software solutions often require to use legacy COM components from a .NET application.
This can be done in two different ways.
And if you do, try WiX installer toolkit...
Regards,
Thomas.