It should be possible to just post-process the .wixobj using your favorite XML parser (assuming there are no binary streams in it). If there are binary streams in it, then I can really say what would happen if you just change the XML portion. Of course, one way around the issue is to compile the binary stream fragments as a separate .wixobj file and then link that in with the modified .wixobj. Should be easier than mucking with the MSI via the MSI API / COM classes / Interop (especially since the MSI type library doesn't play nice with the automagic RCW generation). Although, since the WiX classes already the MSI functions neatly wrapped and there are numerous script examples using the COM classes, maybe directly modifying the MSI wouldn't be so bad.
Just a thought. Anyone foresee any particular dangers of modifying the .wixobj? Thomas S. Trias Senior Developer Artizan Internet Services http://www.artizan.com/ -------- Original Message -------- Subject: Re: [WiX-users] Re-ordered cab files From: John Nannenga <john.nanne...@microsoft.com> To: General discussion for Windows Installer XML toolset. <wix-users@lists.sourceforge.net> Date: 2/25/2009 12:04 PM > I had similar problems a while back and the situation that set me over the > edge was when we encountered absolutely zero install / WiX code changes but > the file sequences were changing [tracked it down to an environment issue, > versions of .Net installed on the machine]. I woke up one morning and > noticed I was starting to go bald (and I'm not even that old); I figured > enough was enough so I went for the brute force method of authoring process > to ensure file sequences remained consistent between the releases. I spent a > lot less time doing that than I did worrying about and attempting to manually > cleanup file sequences. Haven't had the problem since. (Still missing the > hair, though...) > > > > -----Original Message----- > From: Gareth [mailto:gmor...@serif.com] > Sent: Wednesday, February 25, 2009 11:38 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Re-ordered cab files > > > The new elements are contained in a brand new WiX file that is #included at > the end of my existing WXS project file. They are both in new components > with seperate existing DirectoryRefs - it's as simple as it can get. > They're in a newly defined CAB so as to not alter any existing CABs, and the > merge modules themselves (the files that are moving around) are unchanged. > > I was convinced for a while that it had something to do with where in the > WXS file the new components are being defined and so linking would reach > them in a new order, but I've tried 'first' as well as 'last' with no > improvement. It just makes no sense. > > I even tried adding the new filess to the problematic 3rd CAB with > PatchOrder defines as 1 so they'd be at the end of the CAB - hopefully > leaving the existing contents in the same place - but this had no positive > effect. > > Neither version of the 3rd CAB are sorted in any recogniaseable way, they're > just predictably randomly different from each other. > > > John Nannenga wrote: > >> Ref: http://msdn.microsoft.com/en-us/library/aa368060(VS.85).aspx >> -- SDK documentation pertaining to this issue. >> >> Where the rubber then meets the road [within WiX] is within your directory >> elements...if you have any file additions / removals within your directory >> table, that impacts file sequencing. [File sequencing can also be >> impacted based upon what version of .NET is loaded (many scars involved in >> that one)]. >> >> Sometimes, you can get by with using DirectoryRef elements for the file >> additions. If you have any merge modules outside of your control that >> added / removed files, you're close to being hosed. >> >> There are also some patch enhancements that were made within WiX to better >> assist with these types of issues (my knowledge of WiX 2.0 is getting >> shady, been in WiX 3.x for quite some time) using such tools as Torch and >> Pyro (not sure if they are available in Wix 2.0.5805.0 or not). >> >> >> If you're using the WI SDK way of building patches (Patchwiz, admin >> installs, etc...) and using DirectoryRef doesn't get the job done for you, >> you can author a process that 'fixes' the file sequencing between your two >> admin installs prior to patch generation. That's what I resorted to due >> to the .NET item I referenced earlier. >> >> > > ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
