So how do you replace a merge module with a wixlib. A merge module has a cab with the files to be installed in it. AFAIK, a wixlib has no way transporting the files to be installed to the final MSI. So it seems to me that to use a wixlib, you need the wixlib and the binaries to be installed by the wixlib. Correct?
The problem we have is that we are trying to include some components from an older product with a newer product. The older product references the binaries to be installed with a compiler variable set to "..\stage\product\bin" while the new product references them with "stage\product\bin". The newer product is the staging convention going forward. So it seems we will have to revamp the older product's build to stage everything like the new product. Correct? > -----Original Message----- > From: Bob Arnson [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 15, 2006 7:08 PM > To: Arnette, Bill > Cc: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] way to create merge module and > avoiding codeduplication > > Arnette, Bill wrote: > > A merge module should never deliver a component containing > system files > > to the main feature of an application, because this may cause the > > Installer to validate and repair the application each time > the system > > file is used. A .msi file that is intended to accept > components from a > > merge module should be authored so that any components that contain > > system files only belong to features that are separate from the main > > feature of the application. > > > > If your package uses a merge module containing system files > that link > > all the components from the merge module to the main feature of the > > application, an attempt to use the system file may trigger > the Installer > > to try and repair the main feature of the application. If the main > > feature cannot be repaired, the installation may fail. > > > > --- > > > > I presume "system files" are main application files in this context. > > > > I don't think that's the case. The original intent for merge modules > wasn't to do composition; it was focused on redistributable > components, > so "system files" probably means files that get installed into shared > directories. An advertised shortcut does a resiliency check on the > feature the shortcut points to, so as a general rule, the fewer > components in that feature, the better/faster -- regardless > of whether > they come from merge modules. > > That said, merge modules are on the decline, as you can't patch all > consumers of a merge module. (Remember Slammer? It was so bad because > MSDE distributed via merge modules couldn't get the patch.) Microsoft > publishes very few merge modules these days. Avoid them if you can. > > -- > sig://boB > http://bobs.org > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
