Upgrade your Internet Experience
Microsoft.com
Welcome Sign in
Windows Developer Center
Click to Rate and Give Feedback
MSDN
MSDN Library
Windows Installer
Standard Actions
 RemoveExistingProducts Action
RemoveExistingProducts Action

The RemoveExistingProducts action goes through the product codes listed in the ActionProperty column of the Upgrade table and removes the products in sequence by invoking concurrent installations. For each concurrent installation the installer sets the ProductCode property to the product code and sets the REMOVE property to the value in the Remove field of the Upgrade table. If the Remove field is blank, its value defaults to ALL and the installer removes the entire product.

The installer only runs the RemoveExistingProducts action the first time it installs a product. It does not run the action during a maintenance installation or uninstallation.

Sequence Restrictions

The RemoveExistingProducts action must be scheduled in the action sequence in one of the following locations.

  • Between the InstallValidate action and the InstallInitialize action. In this case, the installer removes the old applications entirely before installing the new applications. This is an inefficient placement for the action because all reused files have to be recopied.
  • After the InstallInitialize action and before any actions that generate execution script.
  • Between the InstallExecute action, or the InstallExecuteAgain action, and the InstallFinalize action. Generally the last three actions are scheduled right after one another: InstallExecute, RemoveExistingProducts, and InstallFinalize. In this case the updated files are installed first and then the old files are removed. However, if the removal of the old application fails, then the installer rolls back both the removal of the old application and the install of the new application.
  • After the InstallFinalize action. This is the most efficient placement for the action. In this case, the installer updates files before removing the old applications. Only the files being updated get installed during the installation. If the removal of the old application fails, then the installer only rolls back the uninstallation of the old application.

ActionData Messages

FieldDescription of action data
[1]Removed product.

 

Remarks

Windows Installer sets the UPGRADINGPRODUCTCODE Property when it runs this action.

Send comments about this topic to Microsoft

Build date: 11/12/2009

Tags What's this?: Add a tag
Community Content   What is Community Content?
Add new content RSS  Annotations
Beware when using VS2005 C runtime merge modules      pavouk100   |   Edit   |   Show History
If your installation includes VS2005 runtime merge modules and upgrades existing installation (which also contains the same C /C++ runtime merge modules), avoid placing RemoveExistingProducts action before InstallInitialize, otherwise upgrade on Vista will uninstall already installed SxS runtime modules and silently fails to install them again, obviously breaking all installed programs depending on VS2005 cruntime. (can be cured by MSI 'repair' facility).

Flag as ContentBug
Most Efficient vs. Rollback      PhilWilson   |   Edit   |   Show History
The documentation points out the consequences if the uninstall after InstallFinalize fails, but it's worth adding that the rollback of this uninstall is in fact a reinstall of the just-upgraded product. This will leave you with both old and new versions installed, and it seems unlikely that either will actually work in these circumstances. It's safer to do the RemoveExistingProducts between InstallInitialize and InstallFinalize so that it's included in the install transaction, and a failure will leave you with the original product installed.
When Version Rules Apply      PhilWilson   |   Edit   |   Show History
When RemoveExistingProducts is sequenced in the InstallInitialize area you effectively get an uninstall of the old product followed by an install of the new product. All other things being equal, this means that file versions and Component guids are irrelevant.
When sequenced in the InstallFinalize area the install of the new product happens over the old product, so file versioning rules apply to each file being installed. Component guids also matter because RemoveExistingProducts uses ref counting to decide whether to remove the old files or just decrement the reference count. The components in the new install (files and registry items) are effectively being shared with those in the new product, so it's important to follow component rules.
If you want an upgrade to behave as if the user uninstalled the old product then installed the new one, then sequence RemoveExistingProducts in the InstallInitialize area.
Tags What's this?: Add a tag
Flag as ContentBug
© 2009 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks | Privacy Statement
Page view tracker