Welcome Sign in
Microsoft Developer Network
Click to Rate and Give Feedback
MSDN
MSDN Library
Windows Installer
Major Upgrades
 Changing the Product Code
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.
  • A component may be added to an existing feature without requiring a product code change.

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.

See Also

About Properties
Using Properties
Property Reference


Send comments about this topic to Microsoft

Build date: 6/5/2008

Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
Renaming a shipped binary      ColbyRingeisen   |   Edit   |  
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.
Adding New Components to Existing Features Installs the Feature Tree      Heath Stewart   |   Edit   |  
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.
Defining Component Code      DanL_DeLorme   |   Edit   |  
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.
Processing
© 2008 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Page view tracker