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.Note 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.
Component cannot be run from source. Set this bit for all components belonging to a feature to prevent the feature from being run-from-network or run-from-source. Note that if a feature has no components, the feature always shows run-from-source and run-from-my-computer as valid options.
Component can only be run from source. Set this bit for all components belonging to a feature to prevent the feature from being run-from-my-computer. Note that if a feature has no components, the feature always shows run-from-source and run-from-my-computer as valid options.
Component can run locally or from source.
If this bit is set, the value in the KeyPath column is used as a key into the Registry table. If the Value field of the corresponding record in the Registry table is null, the Name field in that record must not contain "+", "-", or "*". For more information, see the description of the Name field in Registry table.
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.
If this 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 this bit is set, the installer does not remove the component during an uninstall. The installer registers an extra system client for the component in the Windows Installer registry settings.
If this bit is set, the value in the KeyPath column is a key into the ODBCDataSource table.
If this bit is set, the installer reevaluates the value of the statement in the Condition column upon a reinstall. If the value was previously False and has changed to True, the installer installs the component. If the value was previously True and has changed to False, the installer removes the component even if the component has other products as clients.
This bit should only be set for transitive components. See Using Transitive Components.
If this bit is set, the installer does not install or reinstall the component if a key path file or a key path registry entry for the component already exists. The application does register itself as a client of the component.
Set this bit to mark this as a 64-bit component. This attribute facilitates the installation of packages that include both 32-bit and 64-bit components. If this bit is not set, the component is registered as a 32-bit component.
If this is a 64-bit component replacing a 32-bit component, set this bit and assign a new GUID in the ComponentId column.
Set this bit to disable Registry Reflection on all existing and new registry keys affected by this component. If this bit is set, the Windows Installer calls the RegDisableReflectionKey on each key being accessed by the component. This bit is available with Windows Installer version 4.0. This bit is ignored on 32-bit systems. This bit is ignored on the 64-bit versions of Windows XP.Note 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.
Set this bit for a component in a patch package to prevent leaving orphan components on the computer. If a subsequent patch is installed, marked with the msidbPatchSequenceSupersedeEarlier value in its MsiPatchSequence table to supersede the first patch, Windows Installer 4.5 and later can unregister and uninstall components marked with the msidbComponentAttributesUninstallOnSupersedence value. If the component is not marked with this bit, installation of a superseding patch can leave behind an unused component on the computer.
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 a component is marked with this attribute value in at least one package installed on the system, the installer treats the component as marked in all packages. If a package that shares the marked component is uninstalled, Windows Installer 4.5 can continue to share the highest version of the component on the system, even if that highest version was installed by the package that is being uninstalled.
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.