Ouch...I didn't know the performance hit was that bad. My longest build is about 200 seconds so quite shy of the 7 minutes, let alone 40.
Binding the files into the wixpdb did have one distinct advantage though. When building patches the original and target source files aren't needed since all of the files are in the wixpdb and pyro can get the files from there. This is useful since keeping track of 2 files (the msi and wixpdb) and keeping them safe is much easier than keeping track of all the files in your install and hoping someone doesn't decide to delete or change one of them :) I can get the files embedded into the wixpdb by creating a wixout with the -bf option and then generate a msi from that. I'm wondering if others are having the same problem I'm having and by wix automatically embedding the files into the wixpdb make patching with purely wix much easier. Since the wixpdb is essentially a cab file with the binary entries with the installer xml appended to the end I wonder if you couldn't take the copy cab that was built for the product, add the binary files and then append the xml. I'm not sure if this is even possible, I'm not that familiar with the binding of files within wix. Matt On Thu, Apr 2, 2009 at 11:28 PM, Heath Stewart <[email protected]> wrote: > In short, binding files into the wixpdb was unintended and never should've > happened. > > The time it started binding files into the wixpdb was actually a mistake. > The reason that was started was to including binary columns like those found > in the Binary and Icon tables so that differences were available for pyro. > But since WixFile - which stores information about all files - had a binary > column performance was degreded severally. Builds taking around 7 minutes > were now taking almost 40 and it was an unintended change anyway. So that > performance bug was removed (files not found into the wixpdb anymore) while > maintaining differences in binary columns by referencing source file paths. > > But the correct way to get what you want, it seems, is just build your MSI > initually (light ... -out product.msi). By default a wixpdb file is created > from which you can create patches (now including any changes in binary > columns, which wasn't working originally). So you get your MSI and a wixpdb > for building patches - which contains all the same data as a wixout (it > actually is currently just an embedded wixout with future potential for > other things, though nothing has been considered or planned). > > 2009/4/2 Matt Ziegler <[email protected]> > >> Did the behavior of light change to not automatically bind files into the >> wixpdb? If so was this done for the performance of wixpdb generation as >> specified in the release notes of 3.0.5120.0? Finally what is the >> recommended method to bind files into a wixpdb? >> >> I use the wixpdb files for generating patches and before I had to create a >> wixout file first and then create my msi from that. One of the previous >> builds (not sure which one) then started binding the files directly into the >> wixpdb so I stopped building the wixout. >> >> Thanks >> >> Matt >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> WiX-devs mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/wix-devs >> >> > > > -- > Heath Stewart > Deployment Technologies Team, Microsoft > http://blogs.msdn.com/heaths > > > ------------------------------------------------------------------------------ > > _______________________________________________ > WiX-devs mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wix-devs > >
------------------------------------------------------------------------------
_______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
