<< Click to Display Table of Contents >> RayPack > 8.0 > User Guide > PackDesigner > MSI / MST / RPP Based Projects > Building Packages Building Microsoft Patches |
A Windows Installer patch (*.msp file) is a relatively small, self-contained package including the updated resources of an application, and additional metadata, describing which versions and products can receive the patch.
Upgrading applications by delivering an MSP file has certain advantages over the full upgrade procedure: An MSP can contain a minimal set of data necessary to patch, for example a binary difference between files that have been actually changed. This allows users to download an upgrade patch that is much smaller than the full installation package. User customizations of the patched application are usually preserved during the patch update.
RayPack provides an easy way to create a Windows Installer patch for any valid MSI file. These two basic scenarios are supported:
1.Manually preparing two images (old and new) and creating a patch containing the delta
2.Opening any MSI, adjusting required properties and features, and creating a patch against the original MSI contents.
Note: Patching is only available in RayPack Professional or Enterprise edition. |
1.Prepare two images – one for the old application (before the patch) and one for the new one (after the patch)
2.Open the NEW image in RayPack
3.(Optionally) Apply adjustments to necessary properties, resources etc.
4.Press FILE > BUILD (or simply hit F7 on the keyboard) to open the Build dialog
5.Select the target format MSP
6.Select the location where the MSP file has to be saved
7.RayPack will ask for a location of the base image. Select the OLD image when prompted to do so.
8.Patching may take some time, depending on the number and size of included resources (such as files).
9.When the progress indicator disappears, the patch creation has been finished, and the MSP file is available at the selected target location.
Note: RayPack does not require images to be extracted administratively before opening them in RayPack. Any valid MSI (regardless of compression and media layout) can be used in this process. In order to compare the sources, necessary files will be extracted to a temporary location. In such case, make sure that the amount of free space on your hard drive is at least thrice as big as the actual size of the source and target image. |
1.Open any MSI package that will be a base image for patching
2.Apply any adjustments to necessary properties, resources etc. It is recommended to adjust the ProductVersion, PackageCode at this point.
3.Do not save the changes. Doing so would update the base image!
4.Press FILE > BUILD (or simply hit F7 on the keyboard) button to open the Build dialog
5.Select the target format MSP
6.Select the location where the newly created MSP file will be saved
7.RayPack will ask for the location of the base image. Select the same MSI as opened in the first step.
8.Patching may take some time, depending on the number and size of included resources (such as files).
9.As soon as the progress indicator disappears, the patch creation has been finished, and the MSP file is available at the selected target location.
When the patch is built the default settings will be used. This configuration can be adjusted in the Build options view.
In order to change the patch properties (for example the availability of removal functionality) adjust these settings before starting the actual building procedure.
When creating a patch, the following restrictions have to be taken into account:
•Do not change the structure of existing features. New features can be added, and when removing an obsolete feature all child features must be also removed.
•Do not change identifiers of any component (note: use Upgrade tab to synchronize components between updated packages)
•Do not change the name of the MSI package between versions
•Change the ProductCode of the upgraded package if any of the following is true:
oCoexistent installations of old and new product must be possible
oThe name of the .msi file has been changed
oIdentifier of any existing component has been changed
oA component has been removed from an existing feature
oStructure of features has changed (for example, an existing feature is now a child of another existing feature)
oAn existing child feature has been removed from its parent
More comprehensive list of limits and requirements can be found here: