Comparison of PatchWiz and WiX v3 Patch Build

Comparison of PatchWiz and WiX v3 Patch Build

  • Comments 10

The Windows Installer SDK ships a library named patchwiz.dll. This contains the logic to build a patch from pairs of database packages (.msi files, or simply MSIs) along with other configuration properties. Another tool that the SDK ships is msimsp.exe which uses patchwiz.dll and parses command line options. These tools consume an input file with the same format as a database package but with a different set of tables. This is known as a PCP file (because of the .pcp extension).

When we started planning a patch build system for Windows Installer XML (WiX), we considered building a new system that is completely under our control but without using any undocumented APIs or formats. The result was the WiX patch build system that first shipped in version 3.0 and is used by many divisions and other groups throughout Microsoft.

Even while WiX v3 retains the ability to build PCP files for use with patchwiz.dll, it provides new support using the <Patch> element a two tools: torch.exe and pyro.exe, which builds transforms and patches respectively. This gives us the ability to add validation for common problems and the ability to easily filter most changes, though you need to fragment your authoring properly.

The following table is a comparison of patchwiz.dll and the WiX patch build system.

Feature PatchWiz WiX
Ignore certain files to be upgraded by the patch. Yes Yes
Ignore certain other resource types to be upgraded by the patch (ex: registry values, components, etc.).   Yes
Produces binary delta patches. Yes Yes
Creates patches between MSIs. Yes Yes
Maintains relationships between groups of authored resources (ex: files and registry values in the same fragment).   Yes
Supports authoring of validation flags. Yes Yes
Supports authoring of error flags.   Yes
Consumes tertiary MSIs to include additional data in the patch transform. Yes  
Produces easily parsable output for diagnosing authoring issues.   Yes
Can automatically extract compressed files when creating transforms.   Yes

What’s more, if you’re already building with WiX 3.0 or newer, you already have these tools.

Leave a Comment
  • Please add 6 and 5 and type the answer here:
  • Post
  • This is great but my question how many people really use MSP?

    I have a feeling most people don't use it because of all of it's constrains

  • Most organizations in Microsoft - and many other companies that ship large products - use MSPs. Reshipping an entire product MSI and CABs is not a good acquisition experience and is often cost-inefficient.

    Planning for servicing - which I cover a lot in this blog - is also a study in planning a good deployment story for your product. Far too often developers will push off tasks that an application should do - or in some cases, shouldn't even need to do like configure defaults in the registry - to setup and that's what complicates matters. A good product design yields a good deployment story (vice versa can be a forcing function), and a good deployment story (rather, a more simple deployment story) yields easier and faster servicing even through MSPs.

  • I agree with Ran and Heath here.   The planning for servicing is always critical great advice.  However, it doesn't mean that patching is automatically needed for a good servicing plan.

    Certain business areas will have requirements that MSP makes sense for.  I see this for companies like Microsoft and other ISV's that ship high volume software where it's critical to the bottom line to have a highly optimized mechanism.

    However, I honestly believe that this is the edge case.  Major Upgrades as the general case  is probably perfectly acceptable for the vast majority of businesses.    In my 14 years of writing installs for dozens of companies in a  variety of industries, I've only been asked to author a handful of patches while the vast, vast majority of my deliverables have just been full installs.

    BTW, I don't believe MSI/MSP constraints are the reason.  The reality is the entire development pipeline has to be optimized to support patching regardless of the delivery mechanism.  Frankly it's hard work and the cost frequently outweighs the benefit for many people.

  • BTW, just a quick (mild) rant.   I really wish that when companies released patches they would also give the use the choice of getting a fresh rollup without a patch.

    Take Visual Studio 2008 which I find myself reinstalling today.  SP1 has been out a couple years from now ( it wasn't released very long after the original GA was in the first place ).  I download the GA from MSDN  ( 3.81GB - not bad with my 18MB FTTP connection ) and install it.  Pretty painless so far.  Now I download SP1 ( 881MB .. wow, that's a heck of a patch ) and kick off the install.

    Now I've been down this road so I pretty much know what to expect so I grab my grocery list and hit a couple stores.  I come back home about 40 minutes later and it's stil installing.  ( Nice progressbar within a progressbar using ascii text by the way )

    So my point is don't assume that just because you can do a patch and the patch is smaller that you've actually made everyone's experience better.  Personally I would have been happier just installing a slipstreamed 2008 SP1 in the first place.

  • So, thanks for the comparison, this is really nice.

    My question to this is, as I am planning to do patching for the reasons heath added, if there is anything that speaks against using the WiX patching approach?

    What does "Consumes tertiary MSIs to include additional data in the patch transform." actually mean? And what is meant with "to fragment your authoring properly" this is a bit confusing knowing that in wix wxs context there exists the <fragment> tag.

  • Teriary MSIs are used to customize the patch transform - the transform in the pair that merely tells Windows Installer how to locate files, a few patch-specific properties, and any other content (authored into that teriary MSI, which is the diff between that MSI and the baseline MSI) you want. For example, in WiX patch build I coded up a feature to add the value of the AllowRemoval property found in MsiPatchMetadata table (of the MSP) with a prefix that is the patch ID unless you author Patch/@ClientPatchId (then it because [ClientPatchId].AllowRemoval). You can use this both to identify if the patch was baked into an admin image (applied to an MSI installed with msiexec /a, for example) or if it's actually being installed by a client. If the propery is defined, the actual patch is being installed. If it's not defined, your patch was already baked into an admin image. We use this in DevDiv, for example, to decide whether to enable the Uninstall button for a patch (since you can't remove patches from an admin image once installed - they aren't separate entities at that point).

    Generally, you'll never use tertiary MSIs. In my 11 years with Windows Installer I've only ever used it for this purpose.

    But to answer your other question: quite simply, WiX patch build gives you more control than patchwiz and helps prevent you from authoring or building bad patches that could, for example, advertise features (which then aren't updated by that patch or any future patch until fixed - a problem I describe a lot in this blog). Patchwiz takes garbage in, and spits garbage out and almost always without warning you.

  • Hi,

    I've used WiX a few times to make .msi files by modifying working examples.  I'm trying to make my first patch, and getting nowhere after days of effort.

    The main problem is pyro:

    pyro.exe : error PYRO0252 : No valid transforms were provided to attach to the patch. Check to make sure the transforms you passed on the command line have a matching baseline authored in the patch. Also, make sure there are differences between your target and upgrade.

    The main problem seems to be the opaque nature of WiX: No details are available other than this cryptic message.  What's "a matching baseline authored in the patch"?

    Two files are changed in the patch.  The product.wxs files for the old and new versions differ only in the paths for these files.  Why aren’t Torch and Pyro recognizing these changes?

    Any suggestions would be appreciated.




    <?xml version="1.0" encoding="UTF-8"?>

    <Wix xmlns="">



           Manufacturer="Dynamo Corp"


           DisplayName="Sample Patch"

           Description="Small Update Patch"



           <Media Id="5000" Cabinet="">

               <PatchBaseline Id="RTM"/>


           <PatchFamilyRef Id="SamplePatchFamily"/>



           <PatchFamily Id='SamplePatchFamily' Version='1.0.0' Supersede='yes'>

               <ComponentRef Id="SampleComponent"/>





  • @Alan, either 1) there were no changes to SampleComponent or other resources in its fragment, or 2) you didn't specify baseline ID "RTM" when passing the transform to pyro.exe along with the transform created between the old and new versions of your MSI that contains SampleComponent.

  • I'm trying to do a patch, however on my main installer, I am using a Fragment file File.wxs that's been created using Paraffin 3.5 since I have thousands of files to iterate through.

    I'm trying to figure out how I'm supposed to reference that fragment file in the patch. I'm seeing in the previous post here that the ComponentRef Id = "SampleComponent" which I believe is referencing the component in the main installer. Any help would be great

  • @Jason, I'm not familiar with Paraffin but if they allow a File to be in a fragment separate from a component, you can still reference the component (like you mentioned) using WiX v3 patching between MSIs. PatchWiz would require the file to be listed (or, rather, all the other files excluded).

Page 1 of 1 (10 items)