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
