WiX: Patching something you didnt build with WiX using WiX

This post has moved here.

Comments (36)

  1. Tony Juricic says:

    With WiX build 4415 I get:

    torch.exe : error TRCH0001 : The Windows Installer service failed to start. Contact your support personnel

    Exception Type: System.ComponentModel.Win32Exception

    Stack Trace:

      at Microsoft.Tools.WindowsInstallerXml.Msi.Database.GenerateTransform(Databas

    e referenceDatabase, String transformFile)

      at Microsoft.Tools.WindowsInstallerXml.Binder.BindTransform(Output transform,

    String transformFile)

      at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file


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

    Binder temporary directory located at ‘C:UsersmeAppDataLocalTempbhbh


    Unbinder temporary directory located at ‘C:UsersmeAppDataLocalTempbh


    Torch temporary directory located at ‘C:UsersmeAppDataLocalTempkd0mm


  2. Can you provide more info? The command lines you ran. Possibly the msi’s for the target and upgrade?

  3. Tony Juricic says:

    That scary message went away when I created  Patch folder instead of expecting torch to create it.

    Command line was:

    "%WIX%bintorch.exe" -p -a -v -val g -val l -val r -val z Build81adminProduct.msi Build82adminProduct.msi -out PatchDiff.Wixmst

    However now Pyro is not happy and gives me:

    C:newwixpatchPatchDiff.wixmst : error PYRO0104 : Not a valid output file; det

    ail: Invalid character in the given encoding. Line 1, position 1.

    Command line for Pyro is (build patch as well):

    "%WIX%bincandle.exe" Patch.wxs

    "%WIX%binlight.exe" Patch.wixobj -out PatchPatch.WixMsp

    REM "%WIX%binpyro.exe" -delta PatchPatch.WixMsp -out PatchPatch.msp -t RTM PatchDiff.wixmst

    "%WIX%binpyro.exe" PatchPatch.WixMsp -out PatchPatch.msp -t RTM PatchDiff.wixmst

    These commands are actually batch files located in my test folder  c:newwixpatch

  4. Nothing is standing out to me. I dont see anything wrong with what you are doing. I’d likely need more data. Can you file 2 sourceforge bugs? One for the fact that Torch is giving a bad error if a directory does not exist and another one about the latest error. Please attach varios files such as the Diff.wixmst so we can see why its considered an invalid output file. Also, what version of Wix are you using?

  5. Tony Juricic says:

    Will do! WiX version is 3.0.4415.0. Thanks.

  6. Nils Wendelöv says:

    It seems you need to provide -xo also when doing a diff on msi files. That makes the output format to be of wixout format which is implicitly done when using -xi.

    At least that solved the same problem for me.

  7. Kadir says:

    Can you please list a "step by step" instruction on how you do this. I have followed your instructions and can only get a diff.wixmst to be produced, I cannot get patch.wxs etc..

    This is do-able:

    torch.exe -p -xo -ax C:Embeded 1.0product.wixpdb 1.1product.wixpdb -out patchdiff.wixmst

    But how can you execute the next lines when you dont have the product.wxs files?

    candle.exe patch.wxs

    light.exe patch.wixobj -out patchpatch.wixmsp

    pyro.exe patchpatch.wixmsp -out patchpatch.msp -t RTM patchdiff.wixmst

  8. kadir says:

    Your instructions don’t match your example. You say;

    "The difference here is that your patch authoring can be done using the WiX v3 Patch element and it follows the same workflow as patching a WiX v3 based msi after the first stage of creating the diffs."

    Acording to your example referenced the first stage does not make the diffs it makes the .wxs.

    1. Build Target Layout:

    > candle.exe -dVersion=1.0 product.wxs

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

    Another issue is you say;

    "The command lines you need to run are all the same as the ones in my sample: Building a Patch using the new Patch Building System – Part 3. The only difference is that you need to pass the -ax command with a path to extract embedded binaries to instead of the -xi switch."

    Below are the rest of your command lines and the only one that works is 3. Transform (torch.exe)

    If you follow your instructions you get a diff.wixmst and that’s it. None of your instructions explain how to do the next step after creating your diff file, which is 4. Building the Patch (candle.exe, light.exe,pyro.exe)

    If we had better instructions we could do the last step of 4. which is pyro.exe

    Can you please provide step by step instructions and assume you are talking to idiots because we don’t know what you know 🙂

    2. Build the Upgrade Layout:

    > candle.exe -dVersion=1.1 product.wxs

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

    3. Create the transform between your products:

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

    4. Build the Patch:

    > candle.exe Patch.wxs

    > light.exe Patch.wixobj -out PatchPatch.WixMsp

    > pyro.exe PatchPatch.WixMsp -out PatchPatch.msp -t RTM PatchDiff.wixmst

  9. You have to create the patch.wxs file. It is a source file and is not automatically generated for you. You can use the one from my sample on how to build a patch using pyro.

  10. quirrel says:

    hello, after some troubles regarding to use torch on MSI I have finally made a sample msp. I only wondered what does the

    ComponentRef tag beyond <PatchFamily> element  in patch.wxs?

    When entering a reference there, the patch file is really small instead when leaving it blank (none ref tags)???

  11. The ComponentRef means that only that component will be included in the patch. If you leave your patch family empty, it defaults to including all the differences.

  12. Ps says:


    I have a 3rd party setup.exe which internally extracts am MSI and installs some setup. As MSI cannot be installed from inside an MSI, i want to create a merge-module for the setup.exe itself, coz the MSI that the setup.exe extracts has some other dependency file and hence the msi wouldnt run when clicked on it.

    Is there any way to get msm for the setup.exe file?


  13. You probably don’t want to get in the business of repackaging msi’s. That 3rd party relies on the MSI registration in order to be able to service the product. If you use an MSM, you could be left with a security vulnerability and the product you installed wont get the update from the vendor.

    Is it correct to assume that you are installing the 3rd party setup.exe as a customaction from within your msi? If thats what you are doing, I would recommend taking a look at using a chainer/bootstrapper such as the one provided by the Visual Studio "Setup and Deployment" projects, Install Shield, or the chainer being developed as we speak by the WiX community called Burn.

  14. Rajesh says:

    Patch.msp created and installed but it doesnot update the files. What might the issue? In the logs it has picked up the diff file Ids.

  15. Which logs? Are the files you are updating the keypath of the component they are in? Are they versioned or unversioned files? You should take a look at the msi versioning rules for ideas as to why they are not updated. I’d need a lot more information to help any further.

  16. Rajesh says:

    Referring to log of patch installation.

    msiexec /update patch.msp REINSTALL=ALL REINSTALLMODE=amus /L*v patchinst.log

    Files which differs are .aspx files and they are unversioned. Replace/overwrite existing unversioned (i.aspx) to unversioned (i.aspx)

  17. Rajesh says:

    Thanks,i did follow the above examples fully. it works now. After manually added the componentRef to patch.wxs file. But i have huge lists of componentRef, is it possible to specify the ComponentGroupRef instead and I use Paraffin to generate .wxs files and i was trying to avoid the manually task in adding the componentRef. Pls suggest.

  18. Rajesh says:

    just went through the child elements of patchfamily and added DirectoryRef instead of componentRef under patchfamily.  it works great now.

  19. Glad you were able to get it working.

    The references under PatchFamily are not recursive. The follow the Fragment rules which means if you reference something in a fragment, you get everything in that fragment. DirectoryRef wont pull in all the components unless they are defined in the same Fragment.

  20. Rajesh says:

    Problem while patch creation. They were some new directories/files and updated/removed files.

    error PYRO0305 : Removing component ‘com

    _SERVICE_INSTALL_133′ from feature ‘WebService’ is not supported.

    pyro.exe : warning PYRO1110 : Component ‘comp_SERVICE_INSTALL_121’ was added to feature ‘WebService’. If you can not guarantee that this feature will always be installed, you should consider adding new components to new top-level features to prevent prompts for source when installing this patch.

    E:ProductReleaseManagementwebwizwxsSuiteServices.wxs(202) : error PYRO0260 : Product ‘{11111111-1111-

    1111-1111-111111111111}’: Table ‘CreateFolder’ has a new row ‘dir_SuiteService_Common_BPC_7/comp_SERVICE_I

    NSTALL_117′ added. This makes the patch not uninstallable.

    at the last

    pyro.exe : error PYRO0261 : This patch is not uninstallable. The ‘Patch’ element’s attribute ‘AllowRemoval’ should be set to ‘no’

    it doesnot create patch.msp file..

    pls suggest.

    In patch.wxs i get this error even if i use to componentRef or DirectoryRef.

    SuiteServices.wxs doesnot have components per file instead it has component groups.

  21. Did you try doing what the error suggests?

    The ‘Patch’ element’s attribute ‘AllowRemoval’ should be set to ‘no’

    This error comes up because what you are doing will prevent the patch from being uninstalled. If you are ok with that then you have to explicitly say that the patch is not uninstallable on the Patch attribute.

  22. Rajesh says:

    When i set the attribute "AllowRemoval" to no. Then "pyro.exe : error PYRO0261 : This patch is not uninstallable" is gone.

    BUT "error PYRO0305"  and "pyro.exe : warning PYRO1110 :" remains.

    it doesnot create patch.msp file..

  23. The PYRO1110 warning is trying to tell you that it is safer to add components in a patch to new root level feeatures. Adding them to existing features that are not always installed can leave you in some pretty unfortunate situations. Do fix this, add a new feature to your upgrade build and add the component there.

    The PYRO0305 error is telling you that you cannot remove components from features in a patch. If you dont have to remove the content in those components, I would leave them alone. If you have to, you can try to follow the directions on my blog about removing a file from a component. Even then, its not a great idea. Another option would just be to ship empty files instead of the original files if that doesn’t break the product.

    Changing the content and composition of your product isn’t easily done with Windows Installer patches. The WiX tools are preventing you from hitting extremely hard to diagnose problems when you change component and feature composition. If you need to do things like this often, you may want to consider a major upgrade instead of a patch.

  24. Sharat says:

    How do we patch a single file out of a component with multiple files in it? I noticed that you said one way is to generate the admin image so that bigger components can be broken into either smaller or individual components. Any link on how to do that? Thanks!

  25. The admin image path wont let you break apart components. The only time you can change component composition is if you rebase your product with a major upgrade. You can patch a single file in a component only if that file is the keypath of the component. If you want to patch a non-keypath file, you can change that file as well as the keypath file and patch both. Hope this helps.

  26. Sharat says:

    The problem I have is not about the changed files. They are being patched as expected. It is about the unchanged files in that component being included in the patch with the new version number as we can only point to a component instead of a file in the WXS file.

  27. You would need to make sure there is no difference in the other files. If there is no difference, they will be dropped. If you changed the version, then they will be included. Either don’t build them, or copy the original files over top of the rebuilt ones before running pyro.

  28. John Schmitz says:


    Thanks for your efforts! I’ve been trying for many days to build a patch, unsuccessfully. The WIX user community doesn’t seem to have any answers, but I’ve already found several things in this blog that should be in the documentation!

    Here’s what I have: I am using WiX 3.5.1030. I have 2 admin images of my product’s versions 7.0.0 and 7.0.1. The original WIX instructions and documentation do not explain the -xi flag used with torch. I wasn’t getting any errors from torch to lead me to believe that I should check the command line arguments, but I think even if I had, I might not have realized that I should use -a. Your reply to Chris says to use -ax, but I found I needed -a and to supply paths to the .MSI files (see complete command sequence below).

    Question 1:

    -pedantic doesn’t seem to output anything – where would I find the messages?

    Comment 1: Somewhere in this or the other Building a patch … Part 3 blog, I found the answer to one of my questions that no one had answered. I think it’s important to document that if you leave out all component refs, torch will check ALL components. All the examples use a single component, and therefore it’s easy for them to add one ComponentRef. A real setup will have dozens, hundreds or (like mine) over a thousand components.

    Question 2:

    Quite a number of the changed or added components are in merge modules. If you leave the PatchFamily element empty, will torch look at all the components, even the ones added by a merge module?

    Question 3:

    Even though all of the above has resulted in a much larger .wixmst file (more likely to DO something), I am STILL getting the exact same PYRO0252 error from Pyro. I have tried dozens of combinations of naming of the Media Cabinet attribute (what IS this?), the PatchBaseline Id attribute, the PatchFamily Id attribute, etc. I think I’ve tried them all but it doesn’t seem to matter. Here’s the WSX:

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

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


       AllowRemoval=’no’ Manufacturer=’Media Cybernetics, Inc.’ MoreInfoURL=’support.mediacy.com’

       DisplayName=’Image-Pro Plus 7.0.1 Patch’ Description=’Patches an Image-Pro Plus 7.0 installation to 7.0.1′


       <Media Id=’5000′ Cabinet=’RTM.cab’>

         <PatchBaseline Id=’RTM’ />


       <PatchFamilyRef Id="SamplePatchFamily"/>



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




    and here’s the command lines from my automated build’s batch file:

    "%WIX_DIR%torch.exe" -p -notidy -pedantic -a IP7.0TargetImageProPlus7.msi IP701ImageProPlus701.msi -out IPP701Patch.wixmst > patchTorch.log

    @if errorlevel 1 goto StopOnError

    "%WIX_DIR%candle" IPP701Patch.wsx > patchCandle.log

    @if errorlevel 1 goto StopOnError

    "%WIX_DIR%light" IPP701Patch.wixobj > patchLight.log

    @if errorlevel 1 goto StopOnError

    "%WIX_DIR%pyro.exe" IPP701Patch.wixmsp -out IPP701Patch.msp -t IPP701Patch IPP701Patch.wixmst > patchPyro.log

    @if errorlevel 1 goto StopOnError

    How can one troubleshoot the PYRO0252 error? Anything you can suggest would be great!



  29. John Schmitz says:

    I should have added in my epic comment above that I have tried this with and without using the PatchFamilyRef. Doesn’t make any difference if I include the PatchFamily element within the Patch element.

  30. On your -t switch, the two things you need to pass are the patch baseline to match the transform to a cab and the wixmst. In your case, the only patch baseline authored in your patch is "RTM" but you are telling pyro to attach the transform to the baseline "IPP701Patch". Change that to RTM or change the PatchBaseline element to tie "IPP701Patch" to the RTM.cab.

    I’ve always wanted to find a way to make this more intuitive but haven’t come up with a good solution. I hope this solves the problem for you.

  31. Now I’ll answer your other questions since I forgot to 🙂

    Question 1:

    -pedantic doesn’t seem to output anything – where would I find the messages?

    Pedantic is rarely actually used and I dont think Pyro uses it at all which means you wont actually get any more information in this case by passing that switch.

    Question 2:

    Quite a number of the changed or added components are in merge modules. If you leave the PatchFamily element empty, will torch look at all the components, even the ones added by a merge module?

    If you are using admin images (-a) then the merge module content will be included. Being able to patch merge module content as part of your product was one of the things that create the requirement to be able to patch using admin images.

    I want to make sure you are creating admin images and those are the msi’s you are passing to torch. If you aren’t you’ll hit another error because all the files wont be loose and and available to diff.

  32. Wil says:

    Can you please document this step by step. The above instructions are not clear enough and there is no where else on the net that I can see similar instructions.



  33. Hi Wil, can you tell me where you need more clarity so I can help and update accordingly?

  34. Hi Peter,

    after playing with patches for MSI files (using the admin installation way), I decided to write it down for reference: blog.stephenreindl.de/…/creating-patches-with-wix

  35. Akshat says:

    It does not work.

    if i include -xo option in torch.exe then it gives error and does not run.

    if i do not include -xo option and create a .wixmst file then it creates the .wixmst file but when i run pyro then it gives error PYRO0104.

    i am stuck.

    how to make it run.