Extracting COM Information from a COM Server

InstallShield 2014

Project: This information applies to the following project types:

Basic MSI
DIM
InstallScript MSI
Merge Module
MSI Database
MSM Database

Note that for MSI Database and MSM Database projects, COM information cannot be extracted at build time; it is extracted at design time.

The recommended method for registering COM servers is to use Windows Installer tables in the .msi database to make the necessary registry entries for your COM server. With this method, Windows Installer is capable of registering files when they are advertised, and it can safely roll back the registration information in case of a failed installation.

Since each component should have only one portable executable file, the assumption is that all of the registration information belongs to a single file, marked as the key file of its component.

InstallShield supports several methods for extracting COM information from a COM server:

Use the Component Wizard. You can use this wizard to create a new COM server component. With this method, the wizard performs a one-time scan of COM information from the component’s key file.
For a component’s COM Extract at Build setting, select Yes. Since InstallShield extracts the COM data every time that you build a release, this method is helpful if your COM server’s interfaces change frequently. The COM server must be the key file of its component for this method.
Extract the information by right-clicking the file in the Files and Folders view and then clicking Extract COM Data for Key File. Use this method if you have already added the COM server file to a component.

As an alternative to having InstallShield extract the COM data, you can manually add COM information to a component in the component’s Advanced Settings.

If you do not want InstallShield to extract COM information every time that you build a release, select No for the COM Extract at Build setting of the component. Use this method if you want InstallShield to register the file according to the information that is statically contained in the component’s COM Registration advanced setting. This advanced setting stores information about the file’s COM classes, ProgIDs, and so on, that were either extracted in the Component Wizard or entered manually in the Advanced Setting area.

When InstallShield extracts COM information from a COM server, the COM class information is written to the Class, ProgId, and Registry tables of the .msi database.

If you are using InstallShield on a 64-bit operating system, InstallShield can extract COM data from a 64-bit COM server. In order to install the data to the correct locations, the component must be marked as 64 bit. To learn more about 64-bit support, see Targeting 64-Bit Operating Systems.

InstallShield employs a special technique to find all COM information on a COM server without actually registering it. Therefore, COM extraction does not affect the system registry. However, some COM servers’ registration processes depend on existing registry entry values. Although InstallShield has developed an algorithm to avoid this scenario, it may not be foolproof in some extreme cases.

Caution: Some applications, like WinRunner, insert hook .dll files into the COM extraction engine. This causes COM extraction to fail and displays the following message: "ISRegSpy detects following module %1 hooked into this process, which causes ISRegSpy to malfunction. You need to shut the application down and restart COM extraction." If you encounter this message, shut down the application and restart COM extraction, as the dialog box instructs.

Do not select the self-registering property for .exe files that are not self-registering. To self-register an .exe file, you need to launch the .exe file with the /regserver command. However, if the .exe file does not support the command line switch, the .exe file will be launched during extraction at build time.

Note: The definitions of the COM-related Windows Installer tables prevent a COM server from being placed in more than one feature. If a COM server needs to be placed in more than one feature, the following are two available options:

Make the second feature that requires the COM server a child of the first, and place the file in the parent feature.
Use self-registration on the COM server instead of using the COM-related Windows Installer database tables.

See Also