Patches are usually updates for an application. A patch can contain few files with newer versions and executable which needs to be applied to an application. Patching an application can be done through any of the ways mentioned below.

Installing the application in per user context

One recommended and easy approach is to install the entire application to a per user directory “local application data”. This allows a Standard User application to directly patch the files.

Pros/Cons

The main disadvantage to this approach however is when multiple users are using the same machine. This approach means that each user has a copy of the game installed, and patches will need to be re-downloaded per user. This will waste not only user's time and hard drive space, but also increase patch server bandwidth and because any application with standard user privileges can modify the application, it also doesn't protect the application’s executables as well.

Install to a common per machine location

Another method is to install just the non-executable data to a subdirectory in “Common Application data”. This is a shared location for all users and can be modified by Standard User applications.

Pros/Cons

This method minimizes the need to re-patch large files if the application is used from more than one account. It is recommended that the executables are kept in Programs Files to minimize the risk to other accounts on the system. The executables should verify the integrity of the new patch content in the shared directory since that can be modified by any Standard User application. This method has the advantage of working equally well on both Windows XP and Windows Vista, and doesn't require Administrator privileges.

Acquire administrator privileges

The patch executable simply requires administrator privileges to run. With administrator privileges, the patch can directly modify the application files located in Program Files.

Pros/Cons

The advantage of this method is its simplicity. However this method is unsuitable if the application needs frequent patching because if someone with a Standard User account wanted to work on it that required frequent patching, then the user has two choices:

• Be inconvenienced by getting an administrator to login and patch the application, or
• Have their account permanently elevated with administrator privileges.

The latter one is not feasible as it weakens the security of the system as whole. Also when implementing this method, the patch executable must be different from the application executable. The patch executable should be marked with a manifest RunLevel tag of requiresAdministrator to denote it as an application that requires administer privileges.

Using Windows Installer for patching

This method is in par the best one when compared to all other techniques. Here, a Windows Installer is used to install the package (.msi file) and a Windows Installer patch (.msp file) would be distributed to install patches. The package must have an MsiPatchCertificate table and the patch must be digitally signed by a certificate in the table.

Pros/Cons

The main advantage of this method is that patches can be applied with just a Standard User without requiring any elevation prompt. This provides a better user experience because the Standard User account doesn't have to ask an Administrator to install the patch or request permanent Administrator privileges to work on that particular application.

It is possible that this method may work in situations that need frequent patches, but the overhead of using Windows Install patch files in terms of build integration and supporting large numbers of files may make this method less desirable than others.

Patches and Windows Installer

Using UpgradeSync

Use UpgradeSync to find any potential errors or problems between a previous version and an upgraded version of your installation. To use UpgradeSync, make sure that you have access to the previous version of the .MSI. The previous .MSI is used by UpgradeSync to find inconsistencies from the old version to the updated one. Run UpgradeSync following the directions in the tool. For step-by-step directions on how to run UpgradeSync, see the topic titled "Using UpgradeSync" in the On-line Help.

When the comparison is finished, UpgradeSync displays a dialog box listing any problems in your installation. UpgradeSync automatically displays Microsoft's recommended changes to your current installation based on the type of upgrade you plan to make. These errors are the most common causes of patch and upgrade failures reported by Windows Installer users.

Any problems that UpgradeSync can fix are displayed with a checkbox. Mark the checkbox next to a problem, or click the Select All button, for UpgradeSync to fix them automatically. Any remaining problems that do not have checkboxes must be fixed manually. Select each of the errors individually to see the entire message in the Error Details box. Click Finish and UpgradeSync will correct the issues with the checkboxes and verify that the other issues have been fixed correctly.

You will need use UpgradeSync again to verify that the errors have been corrected. Once you have no problems listed in UpgradeSync, run the Patch Wizard to create a patch or use the Upgrade page to create an upgrade.

UpgradeSync lets you find and fix potential problems between versions of your installation before creating a patch or an upgrade. Not only does this save you time, it enables you to implement error-free patches and upgrades for your application.

UpgradeSync performs the following functions to prepare your current installation for patching or upgrading:

• It changes the PackageCode, ProductCode, and ProductVersion properties if necessary.
• It aligns component GUIDs.
• It detects errors that could cause problems with a patch or upgrade and, if possible, fixes them.

Creating patches using Patch Creation Tool in Wise Package Studio

1. Launch the Patch Creation tool from within your Wise product. The Patch Creation tool's Welcome dialog appears. This dialog offers an outline of the steps for creating a patch.
2. Read the information on the Welcome dialog, and click Next when finished. The Specify Patch Settings File dialog appears.
3. The radio buttons on the Specify Patch File Settings dialog indicate whether to Create a new patch file or Open an existing patch settings file. A patch file (.PCP) stores settings from the Patch Creation tool, such as the names of the previous and new .MSIs and whether to include whole files or file patches when compiling the patch. For this exercise, select the radio button to Create a new patch file and click Next. The Specify Previous Versions dialog appears.
4. Use the Specify Previous Versions dialog to add entries for each of the previous versions of an installation that the latest version can patch. Click Add to add a previous version. The Previous Version Details dialog appears.
5. Click Browse to browse to the .MSI for the previous version of your application. Click Open after locating the .MSI.
6. Make any desired changes on the Previous Version Details dialog. The settings in the Validation section of the dialog indicate the requirements of the previous installation on the destination computer in order to install this patch. Please view the online help by pressing F1 on the Previous Version Details dialog for more information about the various fields.
7. Click OK when finished making changes on the Previous Version Details dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI and the Specify Previous Versions dialog shows a target path pointing to a temporary directory where the extracted .MSI resides.
8. Add other previous versions if applicable, then click Next on the Specify Previous Versions dialog. The Specify Upgrade Version dialog appears.
9. The Specify Upgrade Version dialog shows the path to the .MSI that upgrades the previous versions enumerated on the Specified Previous Versions dialog. When launching the Patch Creation tool with an installation project already open, the Upgrade MSI path field contains the path to the .MSI for the current installation project. Click Browse to browse to the upgrade .MSI if the Upgrade MSI path field doesn't already contain the correct information.
10. Click Advanced to display the Advanced Upgrade Version Details dialog. This dialog shows the Patch GUID and a field for Previous Patch GUIDs to replace. Please view the online help by pressing F1 on the Advanced Upgrade Version Details dialog for more information about the fields on the dialog. Click OK when finished making changes to the Advanced Upgrade Version Details.
11. Click Next on the Specify Upgrade Version dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI to a temporary directory, and then the Compile Patch dialog appears.
12. The Compile Patch dialog shows several options for compiling the patch. The first field is the name of the Output .MSP file. Browse to the location where to store the .MSP file, or type in the full path including the file name.
13. The Advanced Settings on the Compile Patch dialog determine whether to create file patches or to use entire files, whether to allow the Product Code or Version Number to differ between the previous and upgrade, and whether to create a log file. Mark the checkboxes for these options to enable them.
14. The Multi-patch Media settings indicate the starting file sequence and disk ID numbers as well as the volume label for the .MSP and the prompt that displays when the application needs to be repaired. Again, please view the online help by pressing F1 on the Compile Patch dialog for more information. Note that the Volume Label on this dialog must match the volume label on the CD or other write-protected media that distributes the patch. Click Next on the Compile Patch dialog to continue the patch creation process.
15. The Patch Creation tool begins creating the patch. A dialog might appear, saying "ProductCodes between Target and Upgraded images do not match; do you want to proceed anyway?" Click Yes to continue creating the patch, or click No to stop. Another dialog might appear, saying "ProductVersions between Target and Upgraded images do not match; do you want to proceed anyway?" Click Yes to continue creating the patch, or click No to stop.
16. When the Patch Creation tool has finished creating the patch, the Compile Patch dialog says Patch creation completed and has a View Log button. Click View Log to view the patch creation log, or click Finish to close the Patch Creation tool.

Editing Patches using Orca

When a patch package is opened in Orca, we will likely see something like the following:

A patch package contains transforms and, optionally, tables. Currently, Windows Installer-supported tables include the MsiPatchMetadata and MsiPatchSequence tables. In order to view the changes a patch would make to a product, we need to open up the target .msi installer package in Orca first. Now we have to either click the Transform -> View Patch menu item or drag-and-drop an .msp package into the window. If that .msp is a small update that targets a latter minor upgrade, apply that minor upgrade using one of the methods described previously first. Once the .msp is applied, we'll see all changes to the product in green as below:

Contents of the Patch File:

Summary Information Stream

• Patch GUID
• Product codes for valid targets
• Transform sub-storages
• List of sources

Transforms

• Contains the changes between the .msi databases
• Modifies the target
• Adds patching entries to the tables
• Two for each target database
• Applied “on the fly” for local installation
• Changes persisted for administrative installations

Cabinet file

• Patch files
• Files added to the application
• Replacement files

Applying the patch:

After installing the previous version of your application that you used in creating the patch, double-click the new patch (.MSP) in the directory specified during the patch creation process to launch the patch installation.

Using Command Lines:

Patching the local installation of the product

msiexec /p patch.msp REINSTALL=[Feature list] REINSTALLMODE=omus

Patching an administrative image

msiexec /a <path to administrative image .msi file> /p patch.msp

Common Patching Problems

Command line parameters for applying a patch

• Must contain REINSTALLMODE and REINSTALL
• If adding a feature, use ADDLOCAL; note that REINSTALL cannot equal ALL

Adding or changing feature and/or component structure

• Cannot change the component GUID
• Cannot add a component to an existing feature

Hope this piece of information is useful for all.

Cheers'
Viju