INFO: Best Practices for Creating Windows Installer Merge Modules |
Q255684
The information in this article applies to:
- Microsoft Windows Installer, versions 1.0, 1.1, 1.2
SUMMARY
There are several scenarios in which you may want to create your own merge module:
- Case 1: For components you have created.
- Case 2: For a third-party component or Microsoft component for which a merge module was not supplied.
This article describes the best practices to follow when creating such merge modules.
MORE INFORMATION
In case 1, it is optional to set both msidbComponentAttributesSharedDllRefCount and msidbComponentAttributesPermanent in the Attributes column of the Components Table for the merge module.
In case 2, you should set both the msidbComponentAttributesSharedDllRefCount and msidbComponentAttributesPermanent in the Attributes column of the Components Table for the merge module.
The attributes msidbCompoenentAttributesSharedDllRefCount and msidbComponentAttibutesPermanent are bitflags stored in the Attributes column of the Component Table. If the msidbComponentAttributesSharedDllRefCount bit is set, the installer increments the reference count in the shared DLL registry of the component's key file. If this bit is not set, the installer increments the reference count only if the reference count already exists. If the msidbComponentAttributesPermanent is set, the installer does not remove the component during an uninstallation. The installer registers an extra system client for the component in the Windows Installer registry settings, ensuring that this component is never removed.
For more information on setting these attributes, see the "Component Table" topic in Windows Installer Help.
Schema
When you are authoring merge modules, make sure you are using the correct schema (page count summary property). For example, if you are trying to register a COM component and you use schema 100, you cannot install side-by-side components.
COM/ActiveX
When you are writing merge modules for COM and ActiveX Components, put as much information as possible in the Class, ProgId, and TypeLib tables. It is good practice to try and avoid using the SelfReg table unless absolutely necessary.
REFERENCES
Application Specifications for Windows 2000
Additional query words:
Keywords : kbAppSetup kbMSI _IK kbVSI
Issue type : kbinfo
Technology : kbWinISearch kbWinI100
Last Reviewed: April 21, 2001 |
