How Patching Works

Determine Which Files are Being Patched

Heath Stewart's Blog — Tue, 21 Feb 2006 22:04:41 GMT

How to determine which files are being patched with a custom action.

File Sequencing and How Files are Located

Heath Stewart's Blog — Fri, 19 May 2006 23:48:41 GMT

How file sequences identify the file source for installation, and how patches resolve source for new files.

Always use Unique Package Codes

Heath Stewart's Blog — Wed, 14 Jun 2006 01:01:52 GMT

Package codes should always be unique - even for different processor architectures.

Be Careful or Even Avoid Using Type 35 Custom Actions

Heath Stewart's Blog — Wed, 14 Jun 2006 18:55:40 GMT

Type 35 custom actions have some serious ramifications to servicing and warrant enough concern to be careful when using them or even avoid using them completely. There is another way.

Cumulative Service Packs with MinorUpdateTargetRTM

Heath Stewart's Blog — Thu, 15 Jun 2006 00:33:03 GMT

How to create cumulative service packs easily to apply with Windows Installer 3.1 and newer.

Find the Product

Heath Stewart's Blog — Thu, 22 Jun 2006 00:36:29 GMT

How to find the ProductCode or the product package in the local cache given a product name.

re: How Patching Works

DaveI — Tue, 27 Jun 2006 14:12:42 GMT

Firstly great blog, nitty-gritty on msi is hard to find.

Once a patch is applied is there anywhere on the client I can "see" the changes to the .msi? Is there a cached .msi knocking about with tranform changes applied that I can look at with ORCA?

After applying a small update in \windows\installer, I can see my original .msi, I can see my .msp, but I cant see an .msi with the .msp applied.

I am changing a condition on a feature with a small update. Patchview shows the condition chnage in the msp file but the change does not seem to be occurring.

Any help greatly appreciated.

re: How Patching Works

Heath Stewart — Tue, 27 Jun 2006 21:05:32 GMT

In Orca open the MSI, the click Transform->View Patch in the menu or just drag-and-drop the MSP right into the window. Orca picks the appropriate transform and you'll see the changes in green.

Keep in mind that the MSI is never actual transforms and persisted (except for administrative installation, which are installation points administrators might use to deploy applications - it's not an installation in the tradition sense). See http://blogs.msdn.com/heaths/archive/2005/11/29/498018.aspx for details.

re: How Patching Works

DaveI — Wed, 28 Jun 2006 10:17:13 GMT

Brilliant.

I thought I don't have a transform menu in my ORCA....checked the aboutbox and version 1.1!

Downloaded ORCA 3.0 from your link and how much better is that. And I never knew that the .msp never actually modified the .msi.

Thanks again.

re: How Patching Works

DaveI — Wed, 28 Jun 2006 12:29:51 GMT

I am confused by "patch uninstall custom action."

I want a custom action to execute when the patch will be uninstalled could you expand details on how to do this.

The custom action is not in the orignal image, the log correctly indicates that the action is skipped during patch install but it is no where to be found in the patch uninstall log.

Presumably this is the problem "There is no method for marking a custom action within a patch package to be run when the patch is uninstalled because the installer does not apply the patch packages being uninstalled.
"
But how does the MsiPatchRemovalList of patch GUIDs help me run the custom action?

Maybe I am missing something obvious, please enlighten me.

re: How Patching Works

Heath Stewart — Wed, 28 Jun 2006 17:34:46 GMT

DaveI, when a patch is uninstalled, it is simply removed and the product is repaired based on other properties, most typically repairing only the features that were changed.

Since the patch isn't available, any custom actions added by the patch wouldn't exist. Instead, you have to have hooks in the original MSI that use - for example - the patch codes in the MsiPatchRemovalList to find DLLs (perhaps the patch code is part of a directory path) and run custom actions from the DLLs.

That said, avoid this situation. You can use the file installation tables and standard actions of Windows Installer to do this, but it requires you sequence your uninstall custom actions accordingly and that might be too restrictive. Rather, design your custom actions from the start to be data-driven so that when the patch is removed and the data gone or updated, the existing custom actions can modify the machine state accordingly as deferred custom actions.

re: How Patching Works

DaveI — Wed, 28 Jun 2006 19:05:20 GMT

Ahh. I see there is no patch uninstall "sequence" as such.

Sadly, the product is long gone out of the door. I will have to piggy-back a custom action already in the original install.

One final question I promise ;)

Should it be possible to add a condition to a feature in a small update?

ORCA is showing that the condition correctly gets added to the condition table, but the feature is still being installed. (If you dont know I appreciate that this is project specific query.)

re: How Patching Works

Heath Stewart — Wed, 28 Jun 2006 21:31:38 GMT

If the feature was installed before, it will be reinstalled if patched or if it is included in the REINSTALL property (or if ALL is specified).

re: How Patching Works

Dave I — Mon, 18 Sep 2006 15:45:04 GMT

I have question on patch sequencing....

I have an accumulative small update patch (targeting say 3 previous small updates) how can I determine and/or define the order in which the transforms are applied?

For a small update is it possible to specify an order, maybe with the MsiPatchSequence\Sequence column? Are transforms applied in order of their sequence number low to high?

Thanks in advance.

re: How Patching Works

Heath Stewart — Tue, 19 Sep 2006 00:16:21 GMT

Dave I, he MsiPatchSequence table is used to sequence patches (rather, patch transforms) in addition to superseding patches. Supersedence is not required. See http://blogs.msdn.com/heaths/archive/2006/06/14/631423.aspx for a larger example of patch sequencing in action.

Also, due to a bug in Community Server, your comment starting "Furthermore" was deleted. Please repost if you remember your question and I'd be happy to answer it.

re: How Patching Works

Dave I — Tue, 19 Sep 2006 13:35:36 GMT

Thanks Heath. Great post that confirmed my suspicions and set me on the right track.

I hate to swear but my problem was "InstallShield 10.5." In a nutshell the patchview just does not appear to be serialised correctly to the project file!!
The patch view consists of a set of tree nodes that appear to dictate how MsiPatchSequence is authored, obviously completely undocumented.

The order appears to be randomised based on the tree node name...honestly I think InstallShield give the Windows Installer technology a bad reputation...

VS 2005 SP1 Takes a While to Install

Heath Stewart's Blog — Sat, 07 Oct 2006 00:18:26 GMT

One of the most-reported feedback issues with Visual Studio 2005 Service Pack 1 Beta is about how long

Save Time when Installing Patches

Heath Stewart's Blog — Thu, 12 Oct 2006 07:11:20 GMT

How to install multiple patches at once to save time.

Mitigating Custom Action Problems for Patches on Vista

Heath Stewart's Blog — Wed, 25 Oct 2006 23:38:42 GMT

Because some of the custom actions in Visual Studio 2005 are authored to impersonate the non-privileged

Rebuilding the Installer Cache

Heath Stewart's Blog — Thu, 30 Nov 2006 22:47:32 GMT

During some operations upgrades internally, a problem arose on some machines where a patch for the Microsoft

Installation Guidelines for User-editable Configuration

Heath Stewart's Blog — Thu, 21 Dec 2006 23:12:22 GMT

A common problem with installations is user-editable files and registry keys. Configuration of this nature

Installation Guidelines for User-editable Configuration

Heath Stewart's Blog — Fri, 22 Dec 2006 00:59:16 GMT

A common problem with installations is user-editable files and registry keys. Configuration of this nature

The Visual Studio 2005 Service Pack 1 Installation Experience

Heath Stewart's Blog — Fri, 29 Dec 2006 13:23:35 GMT

Visual Studio 2005 Service Pack 1 can take a long time to install and may apply to multiple products

The Patch Cache and Freeing Space

Heath Stewart's Blog — Wed, 17 Jan 2007 21:14:42 GMT

When you install a patch using Windows Installer, the .msp file is cached in the %WINDIR%\Installer directory.

Small Updates Should Usually Target a Single Baseline

Heath Stewart's Blog — Sat, 31 Mar 2007 04:12:13 GMT

Generally, small updates target a specific ProductVersion , and with Windows Installer 3.0 and newer

Small Updates Should Usually Target a Single Baseline

RSS It All — Sat, 31 Mar 2007 04:25:31 GMT

Generally, small updates target a specific ProductVersion , and with Windows Installer 3.0 and newer

Custom Action Guidelines

Heath Stewart's Blog — Sat, 21 Apr 2007 05:07:00 GMT

Rob Mensching, father of Windows Installer XML (WiX), blogs about why managed custom actions are a bad

Patch Families Can Only Ever Grow

Heath Stewart's Blog — Wed, 09 May 2007 02:02:51 GMT

Peter Marcu has begun talking about new functionality added into WiX 3.0 that he's been working on a

Why is My Feature Advertised?

Heath Stewart's Blog — Wed, 04 Jul 2007 00:59:32 GMT

Removing a component even through obsolescence or supersedence will cause patched features to appear advertised instead of installed, which causes them to not be patched.

Custom Action Guidelines

Heath Stewart's Blog — Wed, 04 Jul 2007 00:59:41 GMT

Rob Mensching, father of Windows Installer XML (WiX), blogs about why managed custom actions are a bad

Determine Which Files are Being Patched

Heath Stewart's Blog — Wed, 04 Jul 2007 01:00:17 GMT

How to determine which files are being patched with a custom action.

Cumulative Service Packs with MinorUpdateTargetRTM

Heath Stewart's Blog — Wed, 04 Jul 2007 01:01:23 GMT

How to create cumulative service packs easily to apply with Windows Installer 3.1 and newer.

KB928365 for MS07-040 Leaves Some Managed Applications Sluggish

Noticias externas — Sat, 14 Jul 2007 02:54:32 GMT

After installing Security Update KB928365 for the Microsoft .NET Framework 2.0 to fix MS07-040 , some