The Component table lists components and it has the following columns.
Identifies the component record.
Primary table key.
A string GUID unique to this component, version, and language.
Note that the letters of these GUIDs must be uppercase. Utilities such as GUIDGEN can generate GUIDs containing lowercase letters. The lowercase letters must be changed to uppercase to make these valid component code GUIDs.
If this column is null the installer does not register the component and the component cannot be removed or repaired by the installer. This might be intentionally done if the component is only needed during the installation, such as a custom action that cleans up temporary files or removes an old product. It may also be useful when copying data files to a user's computer that do not need to be registered.
External key of an entry in the Directory table. This is a property name whose value contains the actual path, which can be set either by the AppSearch action or with the default setting obtained from the Directory table.
Developers must avoid authoring components that place files into one of the User Profile folders. These files would not be available to all users in multi-user situations and could cause the installer to permanently view the component as requiring repair.
External key to column one of the Directory table.
This column contains a bit flag that specifies options for remote execution. Add the indicated bit to the total value in the column to include an option.
In the case of an .msi file that is being downloaded from a web location, the attribute flags should not be set to allow a component to be run-from-source. This is a limitation of the Windows Installer and can return a feature state of INSTALLSTATE_BADCONFIG.
Setting this bit is recommended for registry entries written to the HKCU hive. This ensures the installer writes the necessary HKCU registry entries when there are multiple users on the same machine.
This bit should only be set for transitive components. See Using Transitive Components.
Use this flag only for components that are being registered by the Registry table. Do not use this flag for components registered by the AppId, Class, Extension, ProgId, MIME, and Verb tables.
If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the ComponentId column.
32-bit Windows applications running on the 64-bit Windows emulator (WOW64) refer to a different view of the registry than 64-bit applications. Registry reflection copies some registry values between these two registry views.
Setting the MSIUNINSTALLSUPERSEDEDCOMPONENTS property has the same effect as setting this bit for all components.
Windows Installer 4.0 and earlier: The msidbComponentAttributesUninstallOnSupersedence value is not supported and is ignored.
If the DisableSharedComponent policy is set to 1, no package gets the shared component functionality enabled by this bit.
Windows Installer 4.0 and earlier: The msidbComponentAttributesShared value is not supported and is ignored.
This column contains a conditional statement that can control whether a component is installed. If the condition is null or evaluates to true, then the component is enabled. If the condition evaluates to False, then the component is disabled and is not installed.
The Condition field enables or disables a component only during the CostFinalize action. To enable or disable a component after CostFinalize, you must use a custom action or the DoAction ControlEvent to call MsiSetComponentState.
Note that unless the Transitive bit in the Attributes column is set for a component, the component remains enabled once installed even if the conditional statement in the Condition column later evaluates to False on a subsequent maintenance installation of the product.
The Condition column in the Component table accepts conditional expressions containing references to the installed states of features and components. For information on the syntax of conditional statements, see Conditional Statement Syntax.
This value points to a file or folder belonging to the component that the installer uses to detect the component. Two components cannot share the same key path value. The value in this column is also the path returned by the MsiGetComponentPath function.
If the value is not null, then KeyPath is either a primary key into the Registry, ODBCDataSource, or File tables depending upon the Attribute value. If KeyPath is null, then the folder of the Directory_ column is used as the key path.
Because folders created by the installer are deleted when they become empty, you must author an entry into the CreateFolder table to install a component that consists of an empty folder.
Note that if a Windows Installer component contains a file or registry key that is protected by Windows Resource Protection (WRP) or a file that is protected by Windows File Protection (WFP), this resource must be used as the KeyPath for the component. In this case, Windows Installer does not install, update, or remove the component. You should not include any protected resources in an installation package. Instead, you should use the supported resource replacement mechanisms for Windows Resource Protection. For more information, see Using Windows Installer and Windows Resource Protection.
For a discussion of the relationship between components and features, see Feature Table.
The installer keeps track of shared DLLs independently of the shared DLL reference count in the registry. If a reference count for a shared DLL exists in the registry, the installer always increments the count when it is installing the file and decrements it when it is uninstalling. If msidbComponentAttributesSharedDllRefCount, is not set, and the reference count does not already exist, the installer will not create one. Note that the SharedDLLs reference count in the registry is incremented for any files installed to the System folder.
If msidbComponentAttributesSharedDllRefCount is not set, then another application can remove the component even if it is still needed. To see how this could happen consider the following scenario:
- An application that uses the installer installs a shared component.
- The msidbComponentAttributesSharedDllRefCount bit is not set and there is no reference count. Thus the installer does not begin a reference count.
- A legacy application that shares this component and does not use the installer is installed.
- The legacy application creates and increments a reference count for the shared component.
- The legacy application is uninstalled.
- The reference count for the shared component is decremented to zero and the component is removed.
- The application using the installer no longer has access to the component.
To avoid this behavior, set msidbComponentAttributesSharedDllRefCount.
Note that system services components should not be specified as run-from-source without being specifically designed for such use. See the ServiceInstall table for more details.
Note that attributes enabling run-from-source installation should never be set for components containing dynamic-link libraries that are going into the system folder. The reason is that if the installation state of the component becomes set to run-from-source by following a feature or by being set in the UI, subsequent calls to LoadLibrary on the DLL would fail.
See also, Controlling Feature Selection States.