WiX: Building a Patch using the new Patch Building System – Part 3

This post has moved here.

Comments (103)
  1. Tim Owers says:

    Small update:

    Instructions for building a Patch using the sample:

    Step 4:

    > pyro.exe PatchPatch.wixout -out PatchPatch.msp -t RTM

    should be

    > pyro.exe PatchPatch.wixmsp -out PatchPatch.msp -t RTM

  2. Yes, good catch. I’ve updated the instructions. Thanks!

  3. Pastriste says:

    Hello, i’m trying the patching system i have a quite big installer.

    I only changed one file from..

    <Component Id="copie_de_newactor.x_1" Guid="{A16E95E6-B27D-411B-A376-96A93B635445}">

    <File Id="copie_de_newactor.x_1" Name="Copie de newActor.x" KeyPath="yes" Source="x:Datacommon3danimationCopie de newActor.x" DiskId="1" />



    <Component Id="copie_de_newactor.x_1" Guid="{A16E95E6-B27D-411B-A376-96A93B635445}">

    <RemoveFile  Id="copie_de_newactor.x_1" On="install" KeyPath="yes"  Name="Copie de newActor.x" />


    to generate a patch and i have the error

    error PYRO0243 : Component ‘copie_de_newactor.x_1’ has a changed keypath. Patches cannot change the keypath of a component.

    So i looked in the PatchDiff.Wixmst and the line <row op="modify" sectionId="{955BA1D1-594E-4678-AD9B-785038FEBC47}/{955BA1D1-594E-4678-AD9B-785038FEBC47}" sourceLineNumber="X:pipeline-onyxMainQAInstallersOnyxSetupOnyxSetup2.wxs*46"><field>copie_de_newactor.x_1</field><field>{A16E95E6-B27D-411B-A376-96A93B635445}</field><field>animation_1</field><field>0</field><field /><field modified="yes" /></row>

    Shouldn’t be a op="delete" ?

    I did test with op="delete" and i have the message pyro.exe : error PYRO0252 : No valid transforms were provided to attach to the patch.

    i’m starting using pyro. I’m sure i missed something somewhere.

    Thanks you

    Best regards,


  4. The first error you got was accurate. You cannot change the keypath file of a component using a patch. This means you cannot delete the file either because the presence of the file is what dictates whether the component is installed. If you want to remove a keypath file, you need to remove the entire component which means you need to remove the entire feature that contains it. Its better just to leave the file there.

  5. Pastriste says:


       Thanks for the reply. I have some error when i generate my Setup.msi. My variables are duplicated. I can remove the duplicate from the wixout and it’s work.

    We are building a setup with 60K files. Currently we use a script to generate our wxs file. We have one component per file and one feature with all the component inside. There is surely a better way to handle our wxs. We set KeyPath="yes" by default without really knowing what it does.

    Do you have any "wxs" strategy we should use?

    thanks alots,

    Best regards,



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

    <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"&gt;

       <Product Id="{955BA1D1-594E-4678-AD9B-785038FEBC47}" Language="1033" Manufacturer="Blabla Inc." Name="v1.05.00" UpgradeCode="{DD431266-3725-4BBB-902A-936CDFD95CA5}" Version="1.05.00">

           <Package Compressed="yes" InstallerVersion="300" />

           <Upgrade Id="{DD431266-3725-4BBB-902A-936CDFD95CA5}">

               <UpgradeVersion OnlyDetect=’yes’ Property=’PATCHFOUND’ Minimum=’1.05.00′ IncludeMinimum=’yes’ Maximum=’1.05.00′ IncludeMaximum=’yes’ />

               <UpgradeVersion OnlyDetect=’yes’ Property=’NEWERFOUND’ Minimum=’1.05.00′ IncludeMinimum=’no’ />


           <Directory Id=’TARGETDIR’ Name=’SourceDir’>

               <Directory Id=’ProgramFilesFolder’ Name=’PFiles’>

                   <Directory Id=’Blabla’ Name=’Blabla’>

                       <Directory Id=’INSTALLDIR’ Name=’Bla’>

    <Directory Id="data_1" Name="Data">

    <Component Id="bla.build_1" Guid="{6CB5A96B-2470-4F61-A237-8B8FC9853BCC}">

    <File Id="bla.build_1" Name="bla.build" KeyPath="yes" Source="x:Databla.build" DiskId="1" />


    <Component Id="bladata.build_1" Guid="{7743C10F-109D-4209-9B67-361D24AB3D21}">

    <File Id="bladata.build_1" Name="blaData.build" KeyPath="yes" Source="x:blaData.build" DiskId="1" />


    <Component Id="bladata.ds.build_1" Guid="{FD92FBF9-BAF0-4730-A263-CC646B91914D}">

    <File Id="bladata.ds.build_1" Name="blaData.DS.build" KeyPath="yes" Source="x:blaData.DS.build" DiskId="1" />



    <Feature Id="bla" Level="1" Title="Bla 1.05.00">

    <ComponentRef Id="log4net.appender.appenderskeleton.activateoptions.html_1" />

    <ComponentRef Id="banksinmultibootdlg.cpp_1" />

    <ComponentRef Id="gxtevbias.html_1" />

    <ComponentRef Id="log4net.core.logimpl.errorformat_overload_3.html_1" />

    <ComponentRef Id="t_5_025.cpp_1" />

    <ComponentRef Id="test_list.vcproj_1" />

    <ComponentRef Id="doc2.htm_1" />

  6. Peter Marcu posted a couple of items on his blog recently that I wanted to link to here so hopefully

  7. The duplicate variable problem is a known issue with a complex fix. Noone has gotten to fixing it yet…

  8. Peter Marcu posted a couple of items on his blog recently that I wanted to link to here so hopefully

  9. Joachim Back says:

    I tried to reproduce the sample and everything worked (files were generated and no warnings or errors) until the last step with pyro. I get this message:

    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.

    I don’t see more log information than that.

  10. Are there differences in the text files you created in the first steps 3 and 4? Also, make sure your Patch authoring has the PatchBaseline set to "RTM" and that you are passing the transform on the command line with RTM as the baseline to tie it to.

    Are you using the sample as is or have you customized anything? When Pyro is reducing the transform down to only the changes, if it ends up reducing everything out then you end up getting this error.

  11. Joachim Back says:

    I had the source code unchanged.

    The text file sample.txt in the sudirs differ a lot.

    The only difference, I see, is that I put the object files not in the two subdirs, but I generated Product10.wixobj anbd Product11.wixobj.

    I worked with Wix V3 3.0.3120.0.

    Is "torch -p …" a must?  I thought -xi automatically includes -xo and -o.

  12. -p is a must. It tells torch to persist all data, including the unchanged data. That data is where the information about what files to compare later on. Without it, you can produce a transform but pyro doesnt know where to grab changed files to put them in your patch.

  13. I fixed the duplicate wix variable problem in a recent build of wix. Try grabbing the latest.

  14. Greg says:

    "Your WiX toolset version should be at least 3.0.3001.0"

    Where can I find the 3.0.3001.0 binaries?  Do have to build WiX myself?  The latest version I see on sourceforge is  3.0.2925.0.

  15. gdean2323 says:

    nevermind I am just now seeing the ‘weekly releases’


  16. Tony says:

    Hi there.  I’m on v3.0.3307.0 and I am trying to do above.  Everything is good to the last command.

    pyro.exe PatchPatch.WixMsp -out PatchPatch.msp -t RTM

    Getting the following error:

    pyro.exe : error PYRO0001 : Index was outside the bounds of the array.

    Exception Type: System.IndexOutOfRangeException

    Stack Trace:

      at Microsoft.Tools.WindowsInstallerXml.Tools.Pyro.ParseCommandLine(String[] a


      at Microsoft.Tools.WindowsInstallerXml.Tools.Pyro.Run(String[] args)


  17. Paul says:

    I’m using 3.0.3412.0 and seeing the same thing as Tony.

  18. Peter says:

    Unfortunately, because the line wraps, the sample is a bit misleading. The -t flag requires 2 arguments. the command line shoudl look like this (notice the path to the mst at the end): pyro.exe PatchPatch.WixMsp -out PatchPatch.msp -t RTM PatchDiff.wixmst

  19. Paul says:

    Thanks for the clarification. I figured that little bit of personal idiocy out yesterday afternoon. Thank you very much for taking the time to put together the article series on patch building.

  20. Paul says:

    Me again,

    This may seem obvious to others, but I’m newish to WIX and patching in general. In my base msi I have 60+ components. In the patch, only one has been updated.

    My question is, in the Patch.wxs file will the <PatchFamily> element only contain a reference to the component that is being updated?



  21. Think of references inside a <PatchFamily> as a way of selecting exactly what you want in your patch.

    You have 2 options:

    1: No <PatchFamilies> with references inside them will result in all the differences between your target and upgrade being included.

    2: Including <PatchFamilies> with references inside them will result in only those things that are referenced being included in the patch.

    Does that answer your question?

  22. Paul says:

    Thanks, that answers my question perfectly.

  23. My new team is using WiX v3.0 to create the MSI-based setups for the upcoming XNA Game Studio 2.0 product

  24. My new team is using WiX v3.0 to create the MSI-based setups for the upcoming XNA Game Studio 2.0 product

  25. Kelly Leahy (Milliman) says:

    Can’t seem to get this to work with 3.0.2925.0.  I changed it a little, but I don’t think I’ve changed it enough to break it.  I’m getting the following:

    pyro.exe : error PYRO0001 : startIndex cannot be larger than length of string.

    Parameter name: startIndex

    Exception Type: System.ArgumentOutOfRangeException

    Stack Trace:

      at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length,

    Boolean fAlwaysCopy)

      at Microsoft.Tools.WindowsInstallerXml.Patch.BuildPairedTransform(String patc

    hId, Output mainTransform, MediaRow mediaRow, String& productCode)

      at Microsoft.Tools.WindowsInstallerXml.Patch.AttachTransforms(ArrayList trans


      at Microsoft.Tools.WindowsInstallerXml.Tools.Pyro.Run(String[] args)

    Any ideas?

  26. Kelly Leahy (Milliman) says:

    Sorry… Missed the line that says "Your WiX toolset version should be at least 3.0.3001.0"

    DOH!  I’ll get a newer version and give it a try.

  27. Not off hand. What did you change? I also need to post an updated sample that matches the current tools and shows how PatchFamilies work.

  28. I’d get the latest. Lots of stuff is being fixed in the patching feature. As recently as this thursday…

  29. john says:

    I have a problem for creating patch file :

    warning PYRO1079 : The cabinet ‘RTM.cab’ does not contain any files.  If this installation contains no files, this warning can likely be safely ignored.Otherwise, please add files to the cabinet or remove it.

    error PYRO0227 : The transform being built did not contain any differences so it could not be created.

    I certainly two files *.wixout are different.

  30. What differences are there? What are you expecting to show up in your patch?

  31. Nick says:

    Anyone run accross something like this:

    C:tstBeta6.1+Patch2>"C:Program Fileswix-3.0.3711.0-binariespyro.exe" –

    delta patchFull.wixmsp -out patchFull.msp -t RTM diffFull02.wixmst -t PATCH1 dif


    Microsoft (R) Windows Installer Xml Patch Builder Version 3.0.3711.0

    Copyright (C) Microsoft Corporation 2003. All rights reserved.

    pyro.exe : error PYRO0001 : Specified argument was out of the range of valid val


    Parameter name: managed

    Exception Type: System.ArgumentOutOfRangeException

    Stack Trace:

      at Microsoft.Tools.WindowsInstallerXml.PatchAPI.PatchInterop.PatchAPIMarshale

    r.CreateArrayOfStringA(String[] managed)

      at Microsoft.Tools.WindowsInstallerXml.PatchAPI.PatchInterop.PatchAPIMarshale

    r.MarshalPOD(Object managedObj)

      at Microsoft.Tools.WindowsInstallerXml.PatchAPI.PatchInterop.PatchAPIMarshale

    r.MarshalManagedToNative(Object ManagedObj)

      at Microsoft.Tools.WindowsInstallerXml.PatchAPI.PatchInterop.CreatePatchFileE

    xW(UInt32 oldFileCount, PatchOldFileInfoW[] oldFileInfoArray, String newFileName

    , String patchFileName, UInt32 optionFlags, PatchOptionData optionData, PatchPro

    gressCallback progressCallback, IntPtr context)

      at Microsoft.Tools.WindowsInstallerXml.PatchAPI.PatchInterop.CreateDelta(Stri

    ng deltaFile, String targetFile, String targetSymbolPath, String targetRetainOff

    sets, String[] basisFiles, String[] basisSymbolPaths, String[] basisIgnoreLength

    s, String[] basisIgnoreOffsets, String[] basisRetainLengths, String[] basisRetai

    nOffsets, PatchSymbolFlagsType apiPatchingSymbolFlags, Boolean optimizePatchSize

    ForLargeFiles, Boolean& retainRangesIgnored)

      at Microsoft.Tools.WindowsInstallerXml.BinderExtension.ResolvePatch(FileRow f

    ileRow, Boolean& retainRangeWarning)

      at Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.CreateCabinet(CabinetWo

    rkItem cabinetWorkItem)

      at Microsoft.Tools.WindowsInstallerXml.CabinetBuilder.ProcessWorkItems()


  32. Please log a bug with full details on SourceForge so we can take a look at this and hopefully get it fixed. The more information you can provide to help us reproduce this, the better. If you dont want to share your source with the world but are willing to provide it just to me, let me know.

  33. Corey Alix says:

    This all worked great, so I tried an experiment.  I download http://wix.sourceforge.net/releases/3.0.3801.0/Wix3.msi and http://wix.sourceforge.net/releases/3.0.3725.0/Wix3.msi with the intention of creating a patch.  After renaming the files I performed these steps:

    torch -xo wix3_20080125.msi wix3_20080201.msi  -out diff.wixmst

    candle patch.wxs

    light patch.wixobj -out patch.wixmsp

    pyro patch.wixmsp -out patch.msp -t RTM diff.wixmst

    When I run torch I get the warning shown below, which I guess is why pyro fails with a NullReferenceException.  Any chance you could provide an example of how to build a patch from these two MSI files?

    torch.exe : warning TRCH1099 : Changing the ProductCode in a patch is not recommended because the patch cannot be uninstalled nor can it be sequenced along with other patches for the target product.

  34. Petermarcu says:

    The servicing story for the Wix3 msi is major upgrade and not patch. They are not designed to be patched. The product code changes build to build. This does not mean it couldnt be patched but probably shouldnt be. The other problem you are hitting is probably because the patching tools work for two msi’s built with the same version of WiX. There are often changes between wix builds that make patching not possible. This is probably the reason you are seeing the exceptions while patching. Can you file a bug on Sourceforge with more details of the exception so we can try to figure out how to provide a better error message? Thanks!

  35. kamol says:

    There is a problem in creating patch of an uncompressed installation. pyro always adds the Compressed attribute while creating a patch. On an uncompressed installation it causes Error 2920 while applying the patch, because MSI tries to uncompress the patched file (because the patch transform marked it as compressed) from media – that fails, because there is no such file in the media. Pyro also adds the PatchAdded attribute to every changed file – I don’t know if that’s right, but I suppose it’s not.

    There is no such problem while applying first patch, it occurs after applying second patch, when trying to "Repair" or while applying a series of two patches with one msiexec call.

    There is a similar problem in patchwiz.dll, but there it was caused by invalid FileSequenceStart value. Patches created with pyro using right Media.@Id don’t have that problem, although the Media.@Id must be chosen carefully.

  36. Petermarcu says:

    I’m not quite sure I followed the first paragraph. Are you saying you are trying to produce a patch that is not compressed? Or are you trying to apply a patch to a layout that you built uncompressed.

    For the last paragraph, we could add error checks in pyro to assure that the added media sequences for a patch do not overlap with the msi. This would be good. Can you file a bug on SF for that one?

  37. kamol says:

    I try to produce a patch that will be applied to a layout that I built uncompressed. Maybe I do something wrong, but the same patch made with InstallShield leaves the Attribute column of File table unchanged for the files the patch changes. Pyro changes this value by ORing 0x5000. Patches made by IS work while those from pyro fail.

  38. Tammy says:

    Hi all, my problem is that I have a few custom actions in my base installer(rtm) and have the same ones in my latest one,  the differences are just base in the files contain within it(add, erased or update) but I keep having thir error:

    torch.exe : error TRCH0001: Item has already been added. Key in dictionary: ‘InstallExecuteSequence/ConfigureIIs’  Key being added: ‘InstallExecuteSequence/ConfigureIIs’

    I thought that if the custom action is present in both installer it’s shouldn’t  be taken as a difference by torch… am I right?

    I would really appreciate the help

  39. Chris Sheppard says:

    Hi, I’m having a few issues with a particular patch.  We’re trying to automate patch generation, given two msi’s.  First question: how important is it that the files retain their component ids?  At any rate, two added files (each with their own component ids again) don’t get added, and only some of the updated files get updated.  The patch claims to have been applied ok, so I’m sifting through the log output, but it’s not making a tonne of sense.  We’re using WiX 3.0.3210.0, so hopefully it has all the latest and greatest stuff…

    Thanks for any help you can render, or just pointers to Somewhere Else to go.

  40. The build you are using is about 7 months old. I always recommend getting the latest version.

    Have you tried using orca to view the patch applied to the product. It will let you see the diff between your target product and patch.

    It is very important to keep identifiers the same when building patches. Also, there are a lot of rules around patching. Do you have one file per component? If not, which one is the keypath and which one are you updating. If you are not updating the keypath, nothing in the component will be updated.

  41. Chris Sheppard says:

    Yes, we have one file per component, which seems a little like overkill to me but is easy to generate for; and it looks like easy to make sure we get all the modifications too.  And Orca shows exactly what I would expect, but then when the time comes to actually DO the patch, it didn’t work.

    Convincing the people generating the package to actually use the same component ids for the same files has made everything work a GREAT DEAL better.  ie it seems to work great!

    Is there a good list of the rules somewhere, or will it just come to me as I continue to peruse the msdn stuff about installer etc.?  Right now my knowledge is more holes than frame, so extra knowledge mostly falls through rather than filling in, but over time I’m absorbing more.

    Ya, I noticed there are Later and Greater things; I just assumed we were ok because our release is beyond the ‘release’ release for 3.x.  I may see about using a newer version, with its binary-delta support…

    The main question I now have is about the type of patch; all the documentation I have seen about patching says there are: minor update, minor upgrade, and major upgrade (I believe); the Patch element has a classification that seems to specify something else entirely… I’m not trying to do major upgrades (ie new product code, new major version number), and I’m just wondering if the classification AFFECTS the type of patch, or if pyro (I would guess?) determines the type based on the transforms given to it?

    Anyway, thanks for all your help, and for all the great work on Wix!

  42. ChrisA says:

    I’m still getting error "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." with WiX 3.0.4123.0 when I change the torch command line to this:

    torch.exe -p -xo 1.0product.msi 1.1product.msi -out patchdiff.wixmst

    Something is different in the generated diff.wixmst file when comparing .msi instead of .wixpdb. Seems like a bug in the torch tool. Or am I missing a command line switch?

    Is there a way to generate a .msp patch package when you only have to .msi files using the WiX toolset?

  43. producing the wixmst from two msi’s is not going to get you all the data you need. That does look like a bug.

    You can use the -ax [binry file location]switch on torch to point at two admin images which you can create from your msi’s using msiexec /a.

    With the way you are doing it currently, it cant compare any of of the files because I’m guessing they are embedded in the msi. Making the admin image expands the files out.

  44. Many times people want to take advantage of the Wix v3 patch building features but didnt build their

  45. Many times people want to take advantage of the Wix v3 patch building features but didnt build their

  46. Sajid says:

    I have tried this example and works fine with .net assemblies and executables.

    but how about the assemblies in the GAC if I did not change the assembly version but file version is changed?

    it does not replace. please advice.

  47. Replacing files in the GAC should work. I do it all the time. Is the file you are trying to update the KeyPath of the component?

  48. Tony says:

    I am considering switching to a new patching system and I wonder how does it deal with, in my case, troublesome file sequence numbers?

    Namely, I have so many files changing between the versions (but changes themeselves are typically very small) that I am afraid I will hit a 16-bit integer limit on file index.

    There is a way to upgrade this field to 32 bit integer but I have no idea how to accomplish that in WiX?

    Wishful thinking: could it be that we are automagically spared from having to think about the file sequence numbers with this new system? Just use it and everything will be just fine … dreaming …

  49. Sequences in your upgrade are ignored and any files with differences are put in the media entry you authored in your patch. This media entry should be higher than your last sequence.

    Wix v3 automatically sets the column type of the sequence to i4 so you shouldnt have any problems with a large number of files.

  50. Tony says:

    Could you, please, elaborate a bit more on ‘this media entry should be higher than your last sequence’ ?

    If I start with media at 5000 and patch 10 files my next entry should be 5010? Then, the next patch, if there are 15 files to be patched, would push this number to 5025?

  51. It needs to be higher than the last sequence in the baseline you are targeting. So if the last sequence in your original product is 5000 then you need to make the media at least 5001 for all patches that apply to the original product. The more I think about this the more I think that we can do the right thing for you in the tools but right now, this is something you have to handle.

  52. Tony says:

    I envy the people who seem to be able to use new patching system. Judging by one WiX bug submission it seems thet there is at least one such person.

    Me, on the other hand, have problems even with the simplest things like running equivalents (on my patch system) of these sample commands:

    > candle.exe -dVersion=1.0 product.wxs

    > light.exe -sval Product.wixobj -out 1.0Product.msi

    Is this one missing -xo option?

    > candle.exe -dVersion=1.1 product.wxs

    > light.exe -sval -xo Product.wixobj -out 1.1Product.msi

    This one has -xo option but is Product.msi a MSI file? Orca can’t open it. So it is not. What is it then? wixout or wixpdb?

    > torch.exe -p -xi 1.0Product.wixpdb 1.1Product.wixpdb -out PatchDiff.Wixmst

    Where do wixpdb’s come from, all of a sudden?

    Are they somehow the byproduct of the build process above? Should I rename MSIs above to have wixpdb extension and use them as input to torch? It turns out that torch doesn’t like them with wipdb extension but accepts wixout extension.

    However Pyro never sees anything to create transform from when passed Diff.Wixmst created this way. No patching!

    Would some good soul please post a downloadable batch file or a set of commands that work on some sample that can be downloaded and tested to work with one of the relatively recent WiX weekly releases?!

  53. I fixed my post. There should not have been a -xo on the second command line to light. The wixpdb is a bi-product of the build. You do not need to specify to have output. It should have an identical name as the msi you are outputting. Think of a dll and its matching pdb when you build a C# project. The wixpdb’s that are output are what you should pass to torch. Let me know if this helps.

  54. Tony says:

    Yes, that helps, thanks! However, I didn’t explain why did I stick to using -xo option.

    It is because I wanted wixpdb that includes binaries, as I can’t exactly reproduce original MSI build environment paths when patching.

    However light help says:

     -bf        bind files into a wixout (only valid with -xo option)

    So I guess I would have to start working with administrative image and -ax option to torch.

  55. Yes, if you didn’t keep your original build around then you are likely going to find admin image patching to be more friendly to you.

    Also, if you build a product that you would like to create patches for, you should not update to a newer version of WiX when you build the upgrades or patches. Stick to exactly the same toolset or you are likely to hit problems.

  56. kamol says:

    some time ago I bothered you about a a patching problem without getting an answer. Now I investigated the problem by myself.

    In short – error 1328 or 2920 occurs while trying to repair a patched installation. 1328 occurs when the package is compressed and 2920 occurs when it’s not.

    The error doesn’t occur always. It occurs if there are at least two patches applied to the product and both of them change the same file. Above that, the patches have to be made with -delta switch and… the changed file has to be large enough(!).

    The problem lies in making a delta patch, which is somehow "intelligent". If the file is small or can be compressed to a small size (I don’t know the limit). The delta for this file is not computed. Instead the whole file is included. But if the file is large enough and the delta is computed, it is put into Patch table. I haven’t found this documented anywhere…

    Pyro always adds PatchAdded and Compressed attributes on modified files as if they were whole included (lines 1854-1857 Binder.cs), so the installer always looks for the replacement of whole file instead of using the delta in Patch table.

    When I commented out these lines and recompiled WiX, my patches started to work, but of course, it is not a resolution for this issue, because it fails for small files.

    Is there a good resolution for this?

  57. Herbert says:

    When I’m using your sample above everything works fine. My problem starts wth the second patch (version 1.2). When I build the diff against version 1.1, patch 1.2 patches version 1.1 correctly but cannot patch the base version 1.0. When I build the diff against version 1.0, patch 1.2 patches version 1.0 correctly but cannot patch version 1.1. What am I doing wrong?

    Thanks Herbert

  58. You need to have multiple baselines in your Patch. Also, your command line to pyro should have multiple "-t [Baseline] [wixmst]" arguments. One for each baseline you want to target.

  59. srinivas says:

    3. Create the transform between your products:

    > torch.exe -p -xi 1.0Product.wixpdb 1.1Product.wixpdb -out PatchDiff.Wixmst

    in the above step where we get Product.wixpdb  file? i haven’t found any such file.

    Plesae tell me what are those files?

  60. srinivas says:

    3. Create the transform between your products:

    > torch.exe -p -xi 1.0Product.wixpdb 1.1Product.wixpdb -out PatchDiff.Wixmst

    in the above step where we get Product.wixpdb  file? i haven’t found any such file.

    Plesae tell me what are those files?

  61. They should be output next to your msi automatically. If they aren’t, you probably dont have a high enough version of WiX v3.

  62. srinivas says:

    I have installed Wix version 3.0.2925.

    is is not enough? Plesae let me know which version i have to install.

  63. Sajid says:

    I was trying to build an msp from 2 msi files built by votive integrated with TFS.

    I keep getting this error:

    ****** ****** *******

    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.

    ****** ****** *******

    commands look like this..

    torch.exe -p old.msi new.msi -out Diff.Wixmst

    candle.exe Patch.wxs

    light.exe Patch.wixobj -out Patch.WixMsp

    pyro.exe Patch.WixMsp -out Patch.msp -t RTM Diff.Wixmst  

    Is the folder structure important?

    and also I will be having only the 2 msi files, old and new, to create the differnce.

  64. John says:

    Hi Peter,

    Good post! I’m seeing a strange problem occur in my patch. The patch is adding additional components that are not been referenced by the patch family. Both the WixMsp and wixobj files are showing the correct components. I can’t seem to understand why these other components have been added.  

  65. John says:

    And I’ll answer my own post…..

    The PatchFamily filters on components and the fragments they are contained within. E.g. if you reference a component thats contained within a fragment with 10 other components. The patch will contain all 11 components.

    I think I need to break up my fragments into smaller modules

  66. Yes, you are correct. If you already shipped a product with large fragments, its not always straight forward to refragment for the upgrade build. You can use the admin image patching feature which auto-fragments your components into their own fragments if that makes your likfe easier.

  67. Lex says:


    I have a problem

    pyro.exe : warning PYRO1097 : File ‘FL_protlib.dll’ in Component ‘SauClt’ was changed, but the KeyPath file ‘FL_saupg.exe’ was not. This file will not be patched on the target system if the REINSTALLMODE does not contain ‘A’. The KeyPath file should also be changed and included in your patch.

  68. That warning is correct. You need to make a change to the keypath file in the component if you want anything in the component to be updated.

  69. Tom says:


    We’ve updated our install to be 100% WiX and now we’d like to update our patching to WiX as well.  I’m able to build and run the above example but when I try to apply it to our install I get pyro.exe : error PYRO0252.  I’ve read a few different blogs about not having compressed files or having the build version of the file in question updated.  Are these things necessary?  The file I’m attempting to patch has a baseline version of 12.6.2671.0 and the patch version is 12.6.2671.9001.  The only mod I made to Patch.wxs was to update the ComponentRef.  Is that sufficient for my simple test?


  70. Can you give me more details about the command you passed to Pyro and Id of the PatchBaseline@Id?

    Feel free to email me the patch.wxs and the command line you passed to pyro. Can you also send me the wixmst file you got when diffing your baseline and upgrade?

  71. Tom says:


    I sent email (not sure if I have the correct address).  Here is the command:

    C:Wix_3.0.4909.0>pyro c:WiXPatchingPatchpatch.wixmsp -out c:WiXPatchingPatchpatch.msp -t RTM c:WiXPatchingPatchdiff.wixmst

    Microsoft (R) Windows Installer Xml Patch Builder version 3.0.4909.0

    Copyright (C) Microsoft Corporation. All rights reserved.

    Here is the Patch.wxs:

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

    <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"&gt;



           Manufacturer="Symantec Corporation"


           DisplayName="Sample Patch"

           Description="Small Update Patch"



           <Media Id="5000" Cabinet="RTM.cab">

               <PatchBaseline Id="RTM"/>


           <PatchFamilyRef Id="SamplePatchFamily"/>



           <PatchFamily Id=’SamplePatchFamily’ Version=’1.0.0′ Supersede=’yes’>

               <ComponentRef Id="bengine.exe.06609F4A_77E8_4877_8B18_0B805D349FD8"/>




    Not sure how to attach the wixmst??

  72. Tom and I worked through email and it turns out that the file that needed patching was included via a Merge Module. In order to patch files from merge modules you have to do one of the two following options:

    1. Follow the steps to patch admin images rather than using the wixpdb. I wrote the steps here: http://blogs.msdn.com/pmarcu/archive/2008/05/30/Patching-something-you-didnt-build-with-WiX-using-WiX-.aspx

    2. Use the melt tool (melt.exe) to decompile your msm into a component group that you can reference directly into your WiX authoring.

  73. Troy says:

    Peter –

    I have a question about the source attribute:


    If your going from v1.0 to v1.1, and the file is new to v1.1, how do you keep a build of v1.0 from aborting?  I am having a hard time figuring out how to structure my versioning folders, where files are introduced in subsequent minor versions, while keeping a common set of wxs files.  Using $(var.Version) seems to be part of the answer…


    – Troy

  74. Hi Troy,

    One option would be to use the preprocessor to only include the new content in the higher version.

    Not sure if this xml sample is going to come through.

    <?if $(var.Version) > 1.0 ?>

    Put your added content here.

    <?endif ?>

    If that doesn’t make things easier for you, I can try to think of other ways.

  75. Troy says:

    Hi Peter –

    This worked!  Thanks.  However I ran into another small issue.  It seems like the patch process will only work for new or existing files .. meaning we are pushing the entire file.  It appears my ComponentRefs, which reference util:XmlConfig patches, are not being applied when I pass in the msp.  Is there some trick to getting these applied?  I am wondering if the "diff" process, using torch, somehow skips these?


  76. Bowyer says:

    How to remove a file with a minor or small upgrade patch?

  77. Bowyer says:

    Hello, Peter:

    I am working on how to make a patch for a product. I have a baseline installation which install a file 123.jar; now I want to make a patch to remove this jar file, how to do?

    Wait for your reply, thank you!

  78. Lucky you! I actually had a post written about remove files in patches that I never published. Here it is: http://blogs.msdn.com/pmarcu/archive/2009/05/19/wix-removing-files-with-patches.aspx

  79. Troy, sorry, I glanced over your question. Can you share your wix files with me? Are you using PatchFamilies? If so, are you referencing something in the same Fragment as the XmlConfig entries?

  80. Harry says:

    I have a multi-language installer and want to make a corresponding multi-language patch. I went through your posts about patching with WiX v3. I’m wondering if the patching system in WiX v3 is able to produce a multi-language patch. If so, could you list the step-by-step instructions based on the example in this blog entry? Thank you.

  81. What method are you using to create your multi-language installer? Are you using language transforms applied to the database at runtime? If so, are you using a bootstrapper to apply the right transform?

    Unfortunately, I haven’t seen a good answer to shipping multi-language patches that doesn’t involve writing a bunch of customactions to apply localized data to the patch at runtime depending on the current locale.

  82. Harry says:

    Hi Peter, Thank you for the quick reply.

    Yes, I’m using language transforms to build a multi-language installer and using a bootstrapper at runtime to install the right language depending on the locale.

    Could you elaborate a little more on what the custom actions would do in a multi-language patch? In my case, there would be updated localized strings and updated locale-dependent data in the patch.

    I read another of your posts: WiX: Patching something you didnt build with WiX using WiX.

    If I understand correctly, torch can take msi as input for base product and upgraded product, but the msi must be admin image where locale has been chosen. My qeustion here is, if the input msi has transforms embedded, would torch be able to accept the transforms? In this case, locale is not chosen yet and thus no admin image is available to torch.

    Recently (in last couple days) in the WiX-user maillist ‘General discussion for Windows Installer XML toolset’, some people asks ‘Passing TRANSFORMS into MSI patch’. I would have the same question except that I intend to pass language transforms into MSI patch. Would you give us some insights on that subject as well?

    Thank you very much for your time and help!


  83. Sorry it took so long to reply. I’ve been extremely busy lately.

    If you create an admin image with the transform already applied, you will get a transform for the locale you applied.

    I’ve never actually done this but if you created a transform for each locale by creating base and upgrade images with the locale transform applied, you could run torch on them. Then you could pass all those transforms to pyro and get them all embedded in the patch.

    When installing the patch, the transform validation settings should pick the right transform to apply based on product language for the installed product.

    Hope this helps…

  84. Essam says:


    I have to say that this is really helpfull.

    What about patching an MSI file created with Visual Studio 2005 and we don’t have the product.wxs for it ??

  85. yixu says:

    I’ve done a bit of searching and I still can’t find the solution for this:  when I try to change the text file in the example to an executable, the executable does not get updated when I run the patch.  Do I have to set some attributes and/or compile the files differently so that executables get patched properly?

  86. Is there a difference between the executables? If there is no difference, it will be dropped from the patch.

  87. Yi Xu says:

    The executables are different; the body of the 1.0 executable looks like:




    Application.Run(new Form1());

    whereas the body of the 1.1 executable looks like:


    When I run the patch and then run the executable in the Program Files directory, I see the "broken" MessageBox and then the form window, thus indicating that the executable was not updated.

    Oddly enough, if I make the 1.1 code look like the 1.0 code except for the MessageBox argument, then pyro complains that there are no differences in the patch even though the executables do differ in a string literal.

    Finally, I get a warning in Product.wxs(11): warning LGHT1079 : The cabinet ‘product.cab’ does not contain any files.  If this Installation contains no files, this warning can likely be safely ignored.  Otherwise, Please add files to the cabinet or remove it.

    Is this related to the executable not being updated?

  88. Can you email me the .wixpdb that is output next to the patch as well as your Patch.wxs authoring?

  89. Yi, it looks like you are not seeing the updated assembly installed because it has an equal version number. It is in the patch.

    Here is the relevant line from the verbose install log:

    MSI (s) (34:54) [08:58:01:456]: File: C:Program Files (x86)Patch Sample DirectoryMyApplication.exe; Won’t Overwrite; Won’t patch; Existing file is of an equal version

  90. shibo says:


    Thanks for the article. Two questions please. Wonder if you can help:

    1.  LGHT0094 -Unresolved reference

    I am trying on my files, with patch.wxs file:

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

    <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"&gt;



           Manufacturer="Dynamo Corp"


           DisplayName="Sample Patch"

           Description="Small Update Patch"



           <Media Id="5000" Cabinet="RTM.cab">

               <PatchBaseline Id="RTM"/>


           <PatchFamilyRef Id="SamplePatchFamily"/>



           <PatchFamily Id=’SamplePatchFamily’ Version=’′ ProductCode=’C7A17B92-870D-4C5E-996D-AF7E7A895C1A’ Supersede=’yes’>

              <ComponentRef Id="cmp12733BDD65D71D0AA0A0B70A8E1ED36D" />

              <ComponentRef Id="cmp515292379E42BE2D327CC29237D973DA" />

              <ComponentRef Id="cmpCA1D24E6B837BE4DEE02C4F246C609AF" />

              <ComponentRef Id="cmpD4DB2A5185C5511E06E6A225782D756C" />

              <ComponentRef Id="cmpD885D72F377ACF30547586DCB601D4A0" />

              <ComponentRef Id="cmpEC4E40176AB70D2F5E33648B18843D06" />

              <ComponentRef Id="cmpE37C52FC1518E696598C4C592EF410BF" />




    I got an error saying:

    light patch.wixobj -out patch.wixmsp

    Microsoft (R) Windows Installer Xml Linker version 3.0.5419.0

    Copyright (C) Microsoft Corporation. All rights reserved.

    patch.wxs(16) : error LGHT0094 : Unresolved reference to symbol ‘MsiPatchSequence:SamplePatchFamily/’ in section ‘Patch:{65DB42A4-5A2E-4CF3-934E-EF125AC9A7D6}’.

    2. ComponentRef under PatchFamily

    Do I have to list all the component refs? Is there a way to default to all?

    Thanks, Shibo

  91. shibo says:


    Error goes away after removing fragment and insert PatchFamily inside patch.

    Can you still help with second question?

    Thanks, Shibo

  92. If you want to include all the changes between your target and upgrade builds, you can either have no patch families, or patch families with no contents. The absence of any patch family contents tells the patch build system to include everything.

  93. whgibbo says:

    Great Blog..

    Was wondering if somebody could help.  I’m trying to create a patch (MSP) for my installation.

    I had the original wixpdb for my original installation, which was handy 🙂

    I thought that I would start with the a simple project first..

    So created the following wix project:

    <!————— Original install.wxs – Start —————!>

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

    <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"&gt;

       <Product    Id="48C49ACE-90CF-4161-9C6E-9162115A54DD"

                   Name="WiX Patch Example Product"



                   Manufacturer="Dynamo Corporation"


               <Package    Compressed="yes"

                           Description="Installs a file that will be patched."

                           Comments="This Product does not install any executables"




           <Media Id="1" Cabinet="product.cab" EmbedCab="yes" />

           <FeatureRef Id="SampleProductFeature"/>



           <Feature Id="SampleProductFeature" Title="Sample Product Feature" Level="1">

               <ComponentRef Id="SampleComponent" />

               <ComponentRef Id="Sample2"/>




           <DirectoryRef Id="SampleProductFolder">

               <Component Id="SampleComponent" Guid="{C28843DA-EF08-41CC-BA75-D2B99D8A1983}" DiskId="1">

                   <File Id="SampleFile" Name="Sample.txt" Source="$(var.ProjectDir)..FilesorgReadme.txt"/>





           <DirectoryRef Id="SampleProductFolder">

               <Component Id="Sample2" Guid="{923248E0-B4B5-4c8c-B343-420EE64CEF88}" DiskId="1">

                   <File Id="SampleFile2" Name="Sample2.txt" Source="$(var.ProjectDir)..FilesorgReadme2.txt"/>





           <Directory Id="TARGETDIR" Name="SourceDir">

               <Directory Id="ProgramFilesFolder" Name="PFiles">

                   <Directory Id="SampleProductFolder" Name="Patch Sample Directory">






    <!————— Original install.wxs – End —————!>

    Build the install.wxs project in the normal way to get the install.wixpdb

    Then duplicated the original install.wxs to fixed.wxs and then duplicated the 2 original txt files, altered the content of both.

    Then altered fixed.wxs as follows:

    <!————— Fixed.wxs – Start —————!>

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

    <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"&gt;

       <Product    Id="48C49ACE-90CF-4161-9C6E-9162115A54DD"

                   Name="WiX Patch Example Product"



                   Manufacturer="Dynamo Corporation"


           <Package    Compressed="yes"

                       Description="Installs a file that will be patched."

                       Comments="This Product does not install any executables"




           <Media Id="1" Cabinet="product.cab" EmbedCab="yes" />

           <FeatureRef Id="SampleProductFeature"/>



           <Feature Id="SampleProductFeature" Title="Sample Product Feature" Level="1">

               <ComponentRef Id="SampleComponent" />

               <ComponentRef Id="Sample2" />




           <DirectoryRef Id="SampleProductFolder">

               <Component Id="SampleComponent" Guid="{C28843DA-EF08-41CC-BA75-D2B99D8A1983}" DiskId="1">

                   <File Id="SampleFile" Name="Sample.txt" Source="$(var.ProjectDir)..FilesPatch1Readme.txt"/>





           <DirectoryRef Id="SampleProductFolder">

               <Component Id="Sample2" Guid="{923248E0-B4B5-4c8c-B343-420EE64CEF88}" DiskId="1">

                   <File Id="SampleFile2" Name="Sample2.txt" Source="$(var.ProjectDir)..FilesPatch1Readme2.txt" />





           <Directory Id="TARGETDIR" Name="SourceDir">

               <Directory Id="ProgramFilesFolder" Name="PFiles">

                   <Directory Id="SampleProductFolder" Name="Patch Sample Directory">






    <!————— Fixed.wxs – End —————!>

    Build the fixed.wxs project in the normal way to get the fixed.wixpdb

    I then created a patch.wxs to create the MSP:

    <!————— Patch.wxs – Start —————!>

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

    <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"&gt;



           Manufacturer="Dynamo Corp"


           DisplayName="Sample Patch"

           Description="Small Update Patch"




           <Media Id="5000" Cabinet="RTM.cab">

               <PatchBaseline Id="RTM"/>


           <PatchFamily    Id=’SamplePatchFamily’




               <ComponentRef Id="SampleComponent"/>




    <!————— Patch.wxs – End —————!>

    Then ran the following commands:

    torch -p -xi install.wixpdb fixed.wixpdb -out Diff.wixmst

    candle.exe patch.wxs -out patch.wixobj

    light.exe patch.wixobj -out patch.wixmsp

    pyro.exe patch.wixmsp -out patch.msp -t RTM Diff.wixmst

    This build the MSP.

    I installed the installed the original msi (install.msi), then installed ran the patch.msp.  It managed to upgrade the txt files, but to my surprise it upgraded both txt files!!

    I had only specified in the Patch.wxs the component ‘SampleComponent’ to be included in the patch..  But seemed to have updated everything..

    I check this using Orca and it appeared that the it was updating all components.

    Is there a know problem or am I doing something wrong ?



  94. From a quick look, everything appears to be correct and the behavior you are expecting should be the result. I can take a look at this on Thursday night when I work on WiX if you haven’t figured it out yet.

  95. I just did this using your exact sample and it worked fine and only updated the one file. Can you send me your directory structure, and the wixmst and wixmsp that you are using as well as the command line arguments you are using?

  96. Yogesh says:

    Hey Peter

    I think you missed somthing

    please take look here he is using  Readme2.txt from patch1 folder & earlier in base version he is using org folder

    <File Id="SampleFile2" Name="Sample2.txt" Source="$(var.ProjectDir)..FilesPatch1Readme2.txt" />

    Second file may get updated because of that.. I am not sure

  97. Arun Kumar says:

    Hello, I have an script to create MSI with a large no of components and it takes more then 1 hour to build MSI (candle + light).

    Now I need to create MSP but creating MSP is again very time consuming as it involves creation of upgraded MSI first and then transform file and then final MSP.

    My client wants me to reduce this time of MSP creation.

    Do you know of any better solution that can be used to create MSP?

    Thanks !

  98. Preethi says:

    By using the above steps, i created patch file. But the changes that are made in merge modules is not reflected after applying the patch. Please advice.

  99. Mahender says:

    Just wondering if somebody could help on my below requirement. Is there any way of achieving this through patching.

    When you install the MSI in a fresh/new server, it should install all the files which are packed inside the MSI.

    When you install the MSI in an existing server, only the changed set of files needs to be deployed and not all the files.

    Thanks in advance.

  100. Jason says:

    Hello All,

    I'm trying to wrap my head around this. I've been building the standard installers using Paraffin to output the componentGroup of all my files to File.wxs and using the VS2010 Wix addin to build my installer.

    Going to the patch, I've found that Votive doesn't support patching in Visual Studio, so I've got to do this process manually.

    What I'm trying to figure out is in the patch.wxs file, how do I reference all my files that are in the File.wxs. I'm assuming i need to be able to do this in place of the "ComponentRefID= 'SampleComponent'" The question is, how to do this. As currently when I try to run pyro -p -xi command I am getting the 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."

    Any help would be appreciated. Thanks in advance!

  101. Dan says:

    Hi Peter,

    Thank you for the nice and useful articles. Wix rocks, even though the documentation is scarce and we struggle sometimes with errors and problems.

    I have installed Wix 3.6 and I'm trying to create a patch using your guidelines. It seems that something is wrong, because I keep getting an error saying:

    Patch.wxs(12) : warning PYRO1079 : The cabinet 'RTM.cab' does not contain any files.  If this installation contains no files, this warning can likely be safely ignored.  Otherwise, please add files to the cabinet or remove it.

    diff.wixmst : error PYRO0227 : The transform being built did not contain any differences so it could not be created.

    I'm trying to create the patch for a web application and I have modified two files: one dll (changed the version from to and one css file. I have checked the new MSI using ORCA and everything looks alright, the dll version is updated and the css is modified. It also works if I install the new MSI. However, I cannot create the patch. This guy is getting the same error: sourceforge.net/…/message.php

    Is there a known issue with creating patches in 3.6?



  102. Aseem Chiplonkar says:

    It may sound stupid but I am confused with these samples.

    Is there a straight forward tutorial which tells me how to create a patch (minor update) installer in Visual Studio 2010?

    The steps would be

       a. Create New project -> Select Windows Installer XML->Setup Project.

       b. Write the installer for a Sample Product which has 2 files. You right click and hit build and it creates the     .msi.

       c. Now create a "Patch.wxs" in the same solution (?) for the minor update for the Sample Product which replaces only one of the 2 files installed.

       d. What should be the tags for GUID, Family DiskID etc.?

       e. Should it be separate VS solution?

       f. Why does it not build and create a patch ".msi"?

    Any help is greatly appreciated!!


    Aseem Chiplonkar

Comments are closed.

Skip to main content