Windows Installer Updates and Patches
See also: RTPatch now also
supports patching of software that was installed using Windows Installer technology. With
RTPatch you can undo a patch without uninstalling the whole application.
If you create a new version of your program and want to be able to update existing
installations either with a full install package or with a patch package, you must follow
some rules. Breaking these rules will cause strange effects like previously installed
features appearing as advertised after the update etc. Here are some guidelines for small
and minor updates (i.e. the ProductCode doesn't change):
- Follow the rules for changing or keeping the ProductCode, ProductVersion and
UpgradeCode, depending of the type of update you are creating. Always change the package
code.
- Do not move sub features. You can add new features and sub features.
- Do not move componentes to other features.
- If you are using the Windows Installer runtime version 1.x:
Do not add components to existing features. If you want to add a component, you must put
it in a new feature. This can be an invisible sub feature of an existing feature. To
install this new feature set the ADDLOCAL property to the name of the new feature. Note
that you cannot combine this with REINSTALL=ALL. Instead use
REINSTALL=ExistingFeature1,ExistingFeature2 ADDLOCAL=NewFeature.
- If you are using the Windows Installer runtime version 2.0 or above:
You can add components to existing features. If you want to add a new feature you can
synchronize the installation state of a new child feature with its parent feature by
setting its Remote Installation property to "Favor Parent" and its Required
property to yes.
- Do not change component codes.
- Do not change the name of the key file of a component.
- You can modify the contents of a component (add, remove or modify files, registry keys
and shortcuts), but only if that component is not shared across features.
- If you remove a file or registry key from a component, you must populate the RemoveFile
or RemoveRegistry table respectively to delete the orphaned resource.
- Do not change the name of the .msi file.
- Don't add or remove dialog controls in multi language setups. The
language transform doesn't get re-cached during a minor update and would no
longer match the controls in the new version.
Written by Stefan Krueger,
updated with a finding by Christopher Painter
Last update: 2011-09-23
In Windows Installer 2.0 a number of changes were made to reduce the need for requiring
the source. Part of this requires work by the setup author in order to avoid needing the
source. Note that completely eliminating the need for the source is not possible. I'll try
to elaborate below on when you may need the source in Windows Installer 2.0.
Source Requirements:
- Your patch applies to a feature with a component containing unversioned files. This will
always require the source for unmodified unversioned files UNLESS you populate the
MsiFileHash table. For more information on the MsiFileHash table, consult msi.chm or
http://msdn.microsoft.com/library/en-us/msi/tref_8fad.asp. The MsiFiler.exe tool provided
in the Platform SDK was also updated to populate this table for you.
- Your patch applies to a feature that is currently run-from-source. In order to apply the
patch, the feature must be transitioned to the local state.
- Your package has the ResolveSource action in its sequence table. This action should only
be run when absolutely necessary.
- The cached package for the product is missing. If the Installer's cached copy of the
package (stored in the %systemroot%\Installer) folder is missing, the package will need to
be re-cached. This requires the Installer to access the source to obtain the package.
- Your patch includes binary patches which cannot successfully apply to the version
currently on the machine. In general, this scenario occurs when you are providing patch 2
to a machine that has the RTM and patch 1 applied. When generating patch 2, the delta was
made between RTM and the new update. So, anyone having patch 1 on the machine (and sharing
a file that is being patched in patch2) will require the source because the binary patch
only works with the RTM version of the file.
- The patch is affecting a component that is currently broken (and to fix it requires the
source)
- The specified REINSTALLMODE includes 'a' which forces an overwrite of all files
regardless of checksum or version. This is a pretty dangerous option in itself, and can
force down-reving of files.
Except for the broken component and missing cached package, most of these requirements
are controllable by the setup author or the admin.
Posted by Carolyn Napier (Microsoft) in newsgroup microsoft.public.platformsdk.msi
Last update: 2002-02-26
This article explains how to create and apply minor and major upgrades by installing a
newer version of the software, not a patch. It describes the following scenarios:
- Reinstalling over the existing version
- Uninstalling the old version with a custom action
- Removing the old version using the upgrade table
This article was written with InstallShield for Windows Installer in mind. The concepts
described apply to other authoring tools as well, however the steps will be different.
If you are using InstallShield Developer 8 you don't need to use the procedure
described here. InstallShield's setup.exe will handle this automatically if you
specify so in the Upgrades view of the IDE.
Remark: If you want to use the method described in this document under
"1: Upgrading by reinstalling" and have added a new feature, you cannot use
"REINSTALLMODE=voums REINSTALL=ALL". Instead use "REINSTALLMODE=voums
REINSTALL=ExistingFeature1,ExistingFeature2 ADDLOCAL=NewFeature". This restriczion
only applies to Windows Installer runtime version 1.x, for MSI 2.0 this is no longer
required.
Upgrading.html Written
by Robert M. Dickau
File size: 12.312 bytes Last update: 2001-02-22
- We are wrapping our MSP files in a custom EXE so that we can minimize patching time by
specifying exactly which features are to be patched. Simply clicking on the MSP may do
either nothing, or it will reinstall the entire product, depending on how you have your
installer authored. Obviously, with a large installation, you don't want to do a full
reinstall during every patch, so a more "surgical" method is required. This
means you have to specify exactly which features are being patched. Depending on the
installation state of the feature in question, you need to do one of the following. If
installed, add the feature to REINSTALL= command line argument. If not installed but part
of the product, ignore it as it will be taken care of when the feature is activated. If
not installed and NOT part of the product (i.e. a new feature) add the feature to
ADDLOCAL= or ADDDEFAULT= command line argument. (comma seperated).
- Don't use MsiApplyPatch(), the command line argument has a 1024 byte limit. Use instead
MsiConfigureProductEx() with PATCH="foo.msp" as part of your command line
argument.
- When adding new subfeatures to existing features, you need to specify the new
subfeatures with ADDLOCAL="H_NEW_FEATURE" (or ADDDEFAULT or ADDSOURCE) in your
command line argument to MsiConfigureProductEx().
- You can do an ADDLOCAL and REINSTALL in the same MsiConfigureProductEx() call but you'll
get feature state flipping if you mix file-based features and registry-based features.
Additionally, you need to make sure that any feature in ADDLOCAL does NOT appear in
REINSTALL, or it won't be added - REINSTALL takes precedence. If you intend to add a new
registry feature while patching files, you'll need to devise a mechanism for storing your
feature states before the MsiConfigureProductEx() call, then restoring them afterwards.
- There is a 100 character limit on all of the transform names applied to an installation.
For each patch, there are [at least] two transforms generated. Blowing past the limit
causes unpredictable results ranging from inability to apply patch, bad reinstalls, and
files left over after uninstall. For example, for two patches, you might get:
:Target01ToUpgrade01;:#Target01ToUpgrade01;:Target02ToUpgrade01;:#Target02ToUpgrade01
if you smash it to
:T1U;:#T1U;:T2U;:#T2U
you can get up to 9 patches. This is a known bug and was fixed in Windows Installer 1.2.
- For more information about patching bugs, see the Bugs
Bulletin for Windows installer.
Written by Jeffrey Klug
Last update: 2001-01-30
Applying Patch Packages
To apply a patch package to a locally installed software package, you must use the
following command line:
msiexec /p patch.msp REINSTALL=ALL REINSTALLMODE=omus
Simply double-clicking the .msp file will only update the cached MSI database, but will
have no effect on the already installed features.
You can isolate end users from this complicated command line process by packaging your
.msp with PackageForTheWeb (PFTW - included on your InstallShield CD or available as free download). When building the
package, on the Delivery Options panel, enter the following command line information (see screen shot):
- Filename: msiexec.exe
- Command line: /p patch.msp REINSTALL=ALL REINSTALLMODE=omus
- Window display: Normal
Note that the Filename must be typed in, it can not be selected from the combo box
(because msiecex.exe is not included in your package).
Now end users can simply run the resulting setup.exe (or patch.exe or whatever you want
to call it). You could even display a Welcome message that explains which fixes are
included in the patch.
Written by Stefan Krueger
Last update: 2000-03-11
WebCasts
Upgrading Windows Installer Based Applications (WebCast)
A 39 minute WebCast given by Mark Lathrope, the Developer Support Product Liaison for
the Windows Installer and Visual Studio Installer authoring tools. The WebCast discusses
upgrade types, related tables and actions and answers frequently asked questions. It does
not talk about patching. The PowerPoint slides and a transcript are also available.
Upgrading Windows Installer Based Applications WebCast
A 32 minute WebCast (also available as PowerPoint presentation) providing an in-depth
discussion of the patching technology provided with the Windows Installer. It discusses
the ways you can create patches and address some of the known issues that customers may
encounter. The presentation is given by Katie Parker, the Windows Installer Product Lead
in Developer Support.
Microsoft Windows Installer Patching WebCast
Copyright © by InstallSite Stefan
Krueger. All rights reserved. Legal
information.
Impressum/Imprint
Datenschutzerklärung/Privacy Policy
By using this site you agree to the license
agreement. Webmaster contact