I would agree with Blair. While I use a combination of InstallShield and WiX to do what I describe, your scenario where the customer builds the final package rather then your internal build team would lend me to suggest that you'd want to ship all WiX to your customers.
--- On Thu, 9/10/09, Blair <os...@live.com> wrote: > From: Blair <os...@live.com> > Subject: RE: [WiX-users] Compression in a Merge Module > To: "'General discussion for Windows Installer XML toolset.'" > <wix-users@lists.sourceforge.net>, chr...@deploymentengineering.com > Date: Thursday, September 10, 2009, 2:08 AM > If you are supplying both the tool > and the framework MSI, why don't you just > go "wix-all-the-way" and do this: > > Framework: supplied wixlib (instead of MSI) that contains > Product element > Tool: harvests files into wixlib (instead of merge module) > Call light to link wixlibs into shipping MSI (instead of > Orca) > > Then you will have total control over the Media element > that controls > compression/etc as well as faster build speeds/etc. > > -----Original Message----- > From: Reuss, Matthias [mailto:matthias.mr.re...@siemens.com] > > Sent: Wednesday, September 09, 2009 11:29 PM > To: chr...@deploymentengineering.com; > General discussion for Windows > Installer XML toolset. > Subject: Re: [WiX-users] Compression in a Merge Module > > Hi Christopher, > > sorry for the late reply. > > The setup is for a group of product catalogues (databases) > that are issued > by several manufacturers. The files are different for each > manufacturer, but > the structure and the setup logic are the same (mostly > determined by the > software that uses the databases). > > I am developing a setup framework (IS project), containing > the logic but > nearly no files, and a tool that harvests a manufacturer's > files into a WiX > file, calls WiX to produce a merge module, calls Orca to > merge the module > into the setup framework, and adjusts some settings in the > MSI package. > > The manufacturers get the framework (as an MSI package) and > the tool, then > they build their setup and ship it to their customers. > > This means that the merge modules are not present at > InstallShield build > time, so I cannot adress them in the IS project. > > Now I got the issue that the compression in the final MSI > package was > considered poor. > > Best regards > > Matthias > > > > -----Ursprüngliche Nachricht----- > > Von: Christopher Painter [mailto:chr...@deploymentengineering.com] > > > Gesendet: Dienstag, 8. September 2009 16:16 > > An: General discussion for Windows Installer XML > toolset. > > Betreff: Re: [WiX-users] Compression in a Merge > Module > > > > I'm curious why you do it this way. > InstallShield has > > Product Configurations and Release Flags that would > alow you > > to build MSI's in various ways to address the > variation > > points you describe. A limitation would be if > you wanted to > > have the same feature tree but different module > inclusions > > but even then the SAAuto interface would allow you to > > > manipulate that as a prebuild authoring step. > > > > Christopher Painter, Author of Deployment Engineering > Blog > > Have a hot tip, know a secret or read a really good > thread > > that deserves attention? E-Mail Me > > > > > > --- On Tue, 9/8/09, Reuss, Matthias > > <matthias.mr.re...@siemens.com> > wrote: > > > > > From: Reuss, Matthias <matthias.mr.re...@siemens.com> > > > Subject: Re: [WiX-users] Compression in a Merge > Module > > > To: "General discussion for Windows Installer XML > toolset." > > <wix-users@lists.sourceforge.net> > > > Date: Tuesday, September 8, 2009, 4:57 AM > > > Thanks for your response. > > > > > > I may have started to handle the issue from the > wrong > > > side: > > > > > > My project consists of several merge modules > created with > > > WiX and a "main" package, which is actually > authored with > > > InstallShield. The merge modules are not > addressed in the > > > InstallShield project, so I first build an MSI > without merge > > > modules (it contains a small CAB file), then one > of the > > > merge modules is merged in using the command-line > version of > > > Orca. Finally some settings (ProductName, > ProductCode, > > > Upgrade Code, PackageCode etc.) are adjusted > corresponding > > > to the merge module used. > > > > > > Orca adds the files from the merge module to the > CAB file > > > orginally created by InstallShield and adjusts > the Media > > > table. > > > > > > So I may have to control the compression of these > files > > > added by Orca. However, I have not found a way to > achieve > > > this. I did try to increase compression in the > > > InstallShield project, however this did not > influence > > > the size of the final CAB file. > > > > > > Best regards > > > > > > Matthias > > > > > > > -----Ursprüngliche Nachricht----- > > > > Von: Pally Sandher [mailto:pally.sand...@iesve.com] > > > > > > > Gesendet: Dienstag, 8. September 2009 11:23 > > > > An: General discussion for Windows Installer > XML > > > toolset. > > > > Betreff: Re: [WiX-users] Compression in a > Merge > > > Module > > > > > > > > As you say the Module element doesn't seem > to have the > > > Media child > > > > element > > > > (http://wix.sourceforge.net/manual-wix3/wix_xsd_module.htm) > > > but > > > > it doesn't really matter. When the merge > module is > > > consumed > > > > into an MSI > > > > its files will be compressed into the media > table of > > > the MSI and > > > > therefore use the same level of compression > as all the > > > other files in > > > > the MSI. > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------------- > > > Let Crystal Reports handle the reporting - Free > Crystal > > > Reports 2008 30-Day > > > trial. Simplify your report design, integration > and > > > deployment - and focus on > > > what you do best, core application coding. > Discover what's > > > new with > > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > > _______________________________________________ > > > WiX-users mailing list > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > > > > -------------------------------------------------------------- > > ---------------- > > Let Crystal Reports handle the reporting - Free > Crystal > > Reports 2008 30-Day > > trial. Simplify your report design, integration and > > deployment - and focus on > > what you do best, core application coding. Discover > what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ---------------------------------------------------------------------------- > -- > Let Crystal Reports handle the reporting - Free Crystal > Reports 2008 30-Day > trial. Simplify your report design, integration and > deployment - and focus > on > what you do best, core application coding. Discover what's > new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
