Home Library Learn Downloads Support Community
Sign in | United States - English | |
10 out of 17 rated this helpful - Rate this topic

Changing the Product Code

The product code is a GUID that is the principal identification of an application or product. See Product Codes.

An update that meets the following guidelines generally does not require a change of the product code and can be handled as a small update, or if the version is to change, as a minor upgrade:

  • The update can enlarge or reduce the feature-component tree but it must not reorganize the existing hierarchy of features and components described by the Feature and FeatureComponents tables. It can add a new feature to the existing feature-component tree. If it removes a parent feature, it must also remove all the child features of the removed feature.
  • The update can add a new component to a new or an existing feature.
  • The update must not change the component code of any component. Consequently, a small update or minor upgrade must never change the name of a component's key file because this would require changing the component code.
  • The update must not change the name of the .msi file of the installation package. Instead, because it modifies the package, it should change the package code. Note that this means that the update can change the tables, custom actions, and dialogs in the .msi file without changing the file's name.
  • The update can add, remove, or modify the files, registry keys, or shortcuts of components that are not shared by two or more features. If the update modifies a versioned file, that file's version must be incremented in the File table. If the update removes resources, it should also update the RemoveFile and RemoveRegistry tables to remove any unused files, registry keys, or shortcuts that have already been installed.
  • The update of a component that is shared by two or more features must be backward compatible with all applications and features that use the component. The update can modify the resource of a shared component, such as files, registry entries, and shortcuts, as long as the changes are backward compatible. It is not recommended that the update add or remove files, registry entries, or shortcuts from a shared component.
  • A small update is shipped as a Windows Installer patch package. (A full product CD-ROM is usually not provided with a small update.)

The product code must be changed if any of the following are true for the update:

  • Coexisting installations of both original and updated products on the same system must be possible.
  • The name of the .msi file has been changed.
  • The component code of an existing component has changed.
  • A component is removed from an existing feature.
  • An existing feature has been made into a child of an existing feature.
  • An existing child feature has been removed from its parent feature.

Note that adding a new child feature, consisting entirely of new components, to an existing feature does not require changing the product code.

New child features can be authored by including msidbFeatureAttributesFollowParent and msidbFeatureAttributesUIDisallowAbsent in the Attributes field of the Feature table. If the minor upgrade only adds new child features, then REINSTALL=ALL is sufficient to force the installation of the new child features. For more information, see Controlling Feature Selection States.

A new child feature may be hidden from the user. To synchronize the installation state of a new child feature with its parent feature, set the msidbFeatureAttributesFollowParent and msidbFeatureAttributesUIDisallowAbsent bits for the child feature.

Related topics

About Properties
Using Properties
Property Reference

 

 

Send comments about this topic to Microsoft

Build date: 2/3/2012

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Defining Component Code
For others that may be trying to determine what is the component code in an installation, it is apparently the ComponentID value in the Component table. See the documentation on the Component Table http://msdn.microsoft.com/en-us/library/aa368007.aspx.
History
Adding New Components to Existing Features Installs the Feature Tree
A patch transform can add a new component to an existing feature tree, but doing so has a significant caveat: doing so will force the existing feature(s) to be installed local. The ramification of doing that means that that feature(s)'s parent feature is also installed, and any descendants of that feature or its parents' features which follow their parent state are also installed. That is, the feature tree gets installed.

Because it's likely that files must be installed when the feature tree is installed, source is required. If source is not readily available, Windows Installer must prompt for it. If Windows Installer cannot prompt for source (silent install) or the source prompt is not satisfied by providing the correct source location, the application of the patch fails.

To prevent the installation from failing, you can make sure the product was installed from a durable source location like that on a network that is always available or cache it locally and have the installation call MsiSourceListAddSource or MsiSourceListAddSourceEx, but this still results in features being installed when perhaps an end user did not want them installed.

Another to workaround to prevent a feature tree from being installed is to add new components to a new top-level feature; or if you're not adding new features in patch transforms, you can use a type 51 custom action to set REINSTALL=ALL scheduled to execute before CostFinalize.
History
Renaming a shipped binary
I think it warrants mentioning that this topic refers to the MSI database package structure, not to installing or uninstalling components. For instance, take the scenario in which a developer renames a binary file that has already been distributed via a Windows Installer package. Since the MSI component rules require the binary to be marked as the key file for a component and they also dictate that you can’t re-name the key file of an existing component, I think the information on this page might mislead the average reader into believing you have to distribute a major upgrade in order to uninstall the binary with the old name and install the binary with the new name. This is not the case since you can add a new component to an existing feature (MSI database package structure), you just need to ensure that you add a new component code for the new binary and then just deprecate the existing component – leaving it in the package but adding a component condition that always evaluates as false and ensuring the msidbComponentAttributesTransitive bit is set for the new component. The former will ensure the depricated component does not get installed and the latter will re-evaluate the condition on systems where the component is already installed and uninstall it. This way, as long as you remember to include the “v” flag of the REINSTALLMODE property to re-cache the updated MSI database, you can distribute a small update or minor update that will uninstall the old file and install the new file.
History