This has been discussed in this mail list and in several bugs before. The issue
is that the documented "Purely Wix" method requires that the builds be done
from different paths because the files to be compared have to have been linked
into their respective MSIs from different locations. Builds that reuse the same
output directories do not conform to that documentation (the example in the
documentation builds each version in its own set of directories).
The current best idea for your situation is to use Melt as described by Bob
here: http://www.joyofsetup.com/2013/07/16/easy-pure-wix-patching-with-melt/. I
haven't verified which versions of the toolset work this way yet, so please let
us know if it works with your build.
The "garbage" at the front of your WIXMST files is a cabinet containing the
binaries coming from bound WIXLIBS (such as the custom actions obtained from
WixExtensions) and is expected to be in that WIXMST (they come from the
associated WIXPDBs). In fact, if that was larger (contained all of the files in
your MSI) you wouldn't have the issue (since the files would be compared from
that cabinet instead of from your build output directories).
> From: steven.par...@nikon.com
> To: wix-users@lists.sourceforge.net
> Date: Mon, 23 Sep 2013 10:32:52 +0000
> Subject: [WiX-users] Cannot patch correctly in 3.6
>
> Hi all,
>
> We’ve had a “Purely Wix” patch build running daily for the last year or so
> with 3.5, it is setup exactly as stated in the documentation
> (http://wixtoolset.org/documentation/manual/v3/patching/wix_patching.html).
> However since upgrading to 3.6, the exact same method now just supplies us
> with an empty patch and the empty cab files message (much like
> http://sourceforge.net/p/wix/bugs/3244/?page=1 and
> http://wixtoolset.org/issues/3946/). The build process shown below has the
> released product wixpdb in PatchSourse and although they are in a different
> location to the new wixpdb files, in the file they reference to the same
> location (X:\output\install….) because this is where the install gets built
> to every time. If this is the cause of the issue, is there no easy way around
> this because otherwise this is going to require a major change to our entire
> build process.
> I have noted that at the top of the wixmst file from 3.6 there are lines and
> lines of garbage up to …..§Ê©sÜM€.\¸páÂ…‹ÿ <?xml version="1.0"
> encoding="utf-8"?><wixOutput type="Transform" codepage="1252" which are not
> there in 3.5 but not sure if this is part of the problem, we’ve tried
> cleaning up the file and removing those lines but doesn’t make any difference.
>
> Current build process:
>
> Set PatchSourse=X:\Install\PRODUCTNAME\Patch\
> Set OutputFolder=X:\Output\install\PRODUCTNAMEPatch\
> Set NewInstall=X:\Output\install\PRODUCTNAME\
> Set WIXDIR=c:\Program Files (x86)\WiX Toolset v3.6\bin
>
> "%WIXDIR%\torch.exe" -p -xi "%PatchSourse%PRODUCTNAMEx32.wixpdb"
> %NewInstall%x86\PRODUCTNAMEx32.wixpdb -out
> %OutputFolder%\PRODUCTNAMEpatch32.wixmst
> "%WIXDIR%\candle.exe" %PatchSourse%Patch32.wxs
> "%WIXDIR%\light.exe" %PatchSourse%Patch32.wixobj
> "%WIXDIR%\pyro.exe" %PatchSourse%Patch32.wixmsp -out
> %OutputFolder%PRODUCTNAMEPatch32.msp -t PATCH
> %OutputFolder%\PRODUCTNAMEpatch32.wixmst
>
> "%WIXDIR%\torch.exe" -p -xi "%PatchSourse%PRODUCTNAMEx64.wixpdb"
> %NewInstall%x64\PRODUCTNAMEx64.wixpdb -out
> %OutputFolder%\PRODUCTNAMEpatch64.wixmst
> "%WIXDIR%\candle.exe" %PatchSourse%Patch64.wxs
> "%WIXDIR%\light.exe" %PatchSourse%Patch64.wixobj
> "%WIXDIR%\pyro.exe" %PatchSourse%Patch64.wixmsp -out
> %OutputFolder%PRODUCTNAMEPatch64.msp -t PATCH
> %OutputFolder%\PRODUCTNAMEpatch64.wixmst
>
>
> We temporarily gave up with that method and instead thought we would try the
> method described here
> (http://bryanpjohnston.com/2013/03/06/automated-patch-building-with-wix-and-visual-studio/)....
>
> msiexec.exe /a "C:\TempInstall\Release\x64\PRODUCTNAMEx64.msi" /qb
> TARGETDIR="C:\TempInstall\Release\x64\Install"
> msiexec.exe /a "C:\TempInstall\Patch\x64\PRODUCTNAMEx64.msi" /qb
> TARGETDIR="C:\TempInstall\Patch\x64\Install"
> "%WIXDIR%\torch.exe" -v -p -xo -ax "C:\TempInstall\Release\x64\Install\\"
> "C:\TempInstall\Release\x64\Install\PRODUCTNAMEx64.msi" -ax
> "C:\TempInstall\Patch\x64\Install\\"
> "C:\TempInstall\Patch\x64\Install\PRODUCTNAMEx64.msi" -out
> %OutputFolder%\PRODUCTNAMEpatch64.wixmst
>
> This successfully built a patch file which could be applied to the original
> install. However the patch appeared to patch our x64 binaries to x86 binaries
> and the application was then unable to start. We are assuming that this is
> because the msi file also contains x86 dlls and an exe even in the x64
> install. We tried removing the ComponentRefs from the PatchFamily in our
> Patch64.wxs file. However this seemed to be ignored and all the files were
> still being patched anyway.
>
> Any help at all on any of this would be gratefully received.
>
> Steve & Sam
> ------------------------------------------------------------------------------
> LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
> 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
> 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
> Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
> http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
