Events
May 19, 6 PM - May 23, 12 AM
Calling all developers, creators, and AI innovators to join us in Seattle @Microsoft Build May 19-22.
Register todayThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The Component table lists components and it has the following columns.
Column | Type | Key | Nullable |
---|---|---|---|
Component | Identifier | Y | N |
ComponentId | GUID | N | Y |
Directory_ | Identifier | N | N |
Attributes | Integer | N | N |
Condition | Condition | N | Y |
KeyPath | Identifier | N | Y |
Component
Identifies the component record.
Primary table key.
ComponentId
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.
Directory_
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.
Attributes
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.
Bit flag |
---|
|
|
|
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. |
msidbComponentAttributesDisableRegistryReflection 512 0x0200 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. |
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. |
Condition
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.
KeyPath
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:
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.
Events
May 19, 6 PM - May 23, 12 AM
Calling all developers, creators, and AI innovators to join us in Seattle @Microsoft Build May 19-22.
Register today