For files that need to be registered, is there anything special that needs to be done or is simply adding the files in the Files view adequate? Is the registry information scanned/grabbed at that time? Or, do I have to add Register Library MSICode actions or the like for each file that needs registering?
Marking files as self-registering is basically a no-no from what I've read so I wouldn't think that would be an option.
THANKS in advance!
Registering OCX's, DLL's, etc. How is this done?
-
Superfreak3
- Posts: 61
- Joined: Tue Feb 06, 2007 9:13 am
Info
Read this post... http://forums.installaware.com/viewtopic.php?t=2258
-
Superfreak3
- Posts: 61
- Joined: Tue Feb 06, 2007 9:13 am
I did read that post before my inquiry.
Also, what are the drawbacks of setting the file(s) to self-register?
In closing, from what I gather, from that post, it really is on a file-by-file basis. There is no real registry info scan when adding the files to my project. Is this basically the case?
HELP Appreciated!!
How is this done? This question was posed at the end of the post you cited, but not answered.Capture the self-reg information directly into the registry view
Also, what are the drawbacks of setting the file(s) to self-register?
In closing, from what I gather, from that post, it really is on a file-by-file basis. There is no real registry info scan when adding the files to my project. Is this basically the case?
HELP Appreciated!!
-
Superfreak3
- Posts: 61
- Joined: Tue Feb 06, 2007 9:13 am
A note on self-registering from WI SDK...
Remarks
It is strongly recommended that installation package authors not use self-registration. Instead they should register modules by authoring one or more of the other tables provided by the installer for this purpose. 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.
A 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 attempting to use a self-registered application on a computer, each user will needs to install a the application on first run because the installer cannot easily determine that the proper HKCU registry keys exist for that user.
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 or EXEs by using the SelfRegModules and SelfUnRegModules actions. See Specifying the Order of Self Registration.
Remarks
It is strongly recommended that installation package authors not use self-registration. Instead they should register modules by authoring one or more of the other tables provided by the installer for this purpose. 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.
A 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 attempting to use a self-registered application on a computer, each user will needs to install a the application on first run because the installer cannot easily determine that the proper HKCU registry keys exist for that user.
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 or EXEs by using the SelfRegModules and SelfUnRegModules actions. See Specifying the Order of Self Registration.
-
MichaelNesmith
- Posts: 3452
- Joined: Thu Dec 22, 2005 7:17 pm
- Contact: