#3244 Patches not longer possible

[Günter Hensges]

Since Version 3.6 it is not longer possible to generate patches. pyro always shows

C:\Project***\Setup\Patch\patch.wxs(10): 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.

If using v3.5 everything worked well. Also often discussed in WWW no reaction from team so far.

[Rob Mensching]

That's just a warning. It should not prevent the creation of the patch.

[Günter Hensges]

You are right. The patch is created but does not have any content although files have explicitly changed. If I run the same patch using msimsp it works correct. Also using wix v3.5 generates a correct patch. I do not believe that this is an expected behavior.

[Rob Mensching]

If that is true, we need a lot more information about what you are doing to begin to understand what might have changed. :) Please provide more information about your actual patch authoring, then change the status back to open. Thanks.

[Brandon Walker]

Please see this post for the details: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WIX-users-Patch-in-Wix-3-6-is-empty-warning-PYRO1079-The-cabinet-cab-does-not-contain-any-files-td7335788.html

I am running into this same issue. I have changed an assembly, have created two full MSIs and have verified my change in the 'new' MSI. However I get an empty .MSP file after using the .WIXMST file created with Torch.

Link to artifacts (logs, command line args, MSI, WIXPDB, WIXMST, etc):https://docs.google.com/file/d/0B__K8bP9DYzTaHR2Y0w0T0hqM3c/edit?usp=sharing

[Brandon Walker]

Update: As advised in the forum post, downgrading to v3.5 solved my issue without any code/command argument change whatsoever.

[Blair]

Brandon, could you please provide the same artifacts from v3.5 for comparison? The 3.6 wixmst file shows identical file paths for "current" and "previous", which pyro will interpret as "unchanged file".

[Brandon Walker]

Hi Blair,

Thanks for the response. I think you are onto something. I don't change the folder path before patching - I can try to spin up a new folder for each patch and test it. Strange how I don't need to do this for 3.5. I wonder if something changed in Pyro that would cause this? Maybe it was infact broken in 3.5.

Here is the link to the 3.5 artifacts with a working patch:
https://docs.google.com/file/d/0B__K8bP9DYzTOE4tQWU3bVlUeUE/edit?usp=sharing

[Blair]

Brandon,

For your 3.5 the file references in the wixmst (the ones I inspected) come from directories like this:

Previous: C:\Program Files\BST Global\Novo\SmartClient\
Patch: C:\Program Files\BST Global\Novo\Deployment\Catalog\patch_data_PatchDir\

whereas the 3.6 wixmst had those same files coming from the same folder (I don't remember which one it was). The paths come from the corresponding wixpdb files, so that means that the paths were different when the corresponding MSIs were created, thus giving Pyro actual files to compare.

There is some difference in the way you are building between the two toolsets. So far Pyro is working as designed in these two cases.

Blair

[Robert Gray]

Hi guys,

I've been working on an msi patching solution for my company and I have encountered this problem. To try and help I have a test project which illustrates the problem.

Inside are 2 identical projects with their output and build logs, one built with 3.5 and the other with 3.7.

Hope this helps,
Robert

[Blair]

Robert,

There is only one copy of Test.XML outside of the MSI files in your solution and Pyro can't yet directly retrieve files from MSI files (we're working on that one). Thus when Pyro compares the file against itself it matches perfectly and the file is excluded from consideration.

It's actually a bug that your scenario appears to work in 3.5 (and delta patching wouldn't have worked there at all).

If you had a copy of your baseline "binaries" you might try adding the -bt switch to Pyro to see if that fixes things.

We are still working to enable your scenario, but for today this is still working as designed.

Blair Murri

[Robert Gray]

Thanks for the info Blair.
Is there a timeline for when 3.8(if that is where this might be fixed) is due to be released?
I am in need of vs2012 support and this is the only issue holding me back.

[Blair]

I'd like to have this "fixed" in 3.8 (meaning enabling torch/pyro to extract the baseline files directly through the MSIs) but I don't know if that will happen or not at this point.

However, if you have a copy of the files in your baseline laid out in the same filesystem tree as they were when the MSI(s) were built, you can use the -bt flag on Pyro to tell pyro where the original files can be found. Alternately if you compile everything into bound wixlibs and your baseline MSI simply links/binds bound wixlibs that should work today.

These are two workarounds for this issue. Not everyone can use them, but they may be useful for anyone that can.

[Robert Gray]

Thanks Blair,
Using the wixlibs works wonderfully!

[Christian Hennig]

Good morning,

we are using the way of building patches as described in WiX help "Patch Building Using Purely WiX", meaning that we are building the delta from the wixpdb's using torch.

The only difference to the sample is that the files for the different versions are always in the same location during build of the baseline msi's, because we are using a source control tool.

Since WiX 3.6 we get the mentioned warning of empty cabinet file.

It looks like WiX 3.6 has some optimization in it to avoid checking for differences in files originated from the same location.

That was definitely working with WiX 3.5.

We are really looking forward to a solution for this issue.

Christian Hennig