If Merge Modules look like they will work, I'd use .wixlibs instead ( http://www.robmensching.com/blog/posts/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them). The WiX toolset's reusable functionality (from the Extensions and all the UI) use .wixlibs. The Wix.chm has a nice section on how to customize dialogs. I'd start there. Without more details about your exact project it's hard to provide more detailed advice. <smile/>
On Thu, Oct 22, 2009 at 1:27 AM, Thomas Due <thomas....@scanvaegt.dk> wrote: > I have been studying the documentation and the tutorial and come to the > conclusion that patching is out, since that is essentially just the > difference between two installers which is exactly what I want to avoid; > Writing two installers... > > So, my next thought is: How about merge modules then? > > What I mean is, that I put all the common stuff into a merge module, it > seems that it can contain all the logic regarding files and components > and installing/starting services etc. > > Then I write the installer for each customer, which contains only the > customer specific bits and adds the merge module containing all the > common bit etc. > > So far so good. But how about the UI? Can I contain MOST of the gui in > the merge module and only add a few customer specific dialogs (if > necessary) in the customer installer, and if so, how do inject dialogs > like that? > > Best regards, > Thomas Due - Software Developer > > -----Original Message----- > From: Thomas Due > Sent: 22. oktober 2009 09:13 > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] How to best install generic system with > customerspecific add-ins > > I am currently finishing up on a generic system which we will sell to > many different customer with different needs. So, as a result this > generic system is based on extensions, or add-ins. > > Now I am thinking how to best write an installer for this. > Although I could copy-n-paste the entire WiX project every time I make a > new customer-specific extension, I think that is quite the wrong way to > go about writing the installer for this system. > > So, I am thinking patches, or maybe transformations? > > An installer for the system itself, and then a patch with the customer > specific bits. This way, I get to maintain a single installer with > upgrade codes etc. and a simple patch installer for each customer > project. On paper that should be simple enough, but how do I do that? > > I am currently still learning WiX, so my knowledge is, at best, shaky. > So I need a bit of help. > > How do I create patches for a specific installer, and is the plan > actually sound? > > Best regards, > Thomas Due - Software Developer > > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
