Cool, that actually sounds like a clever plan. Thanks for the input. Best regards, Thomas Due
-----Original Message----- From: Blair [mailto:os...@live.com] Sent: 23. oktober 2009 10:29 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to best install genericsystem withcustomerspecific add-ins The difference between wixlibs and shared wix fragments is that the wixlibs are simply several shared compiled wix fragments joined into a single "library" file. That would ensure you don't have multiple copies of the sources, but would require that you compile them, either from their own projects in your solution(s) or into some "super-library" repository you simply grab at either buildtime or version control sync time. Either one is usually vastly superior to merge modules. Merge modules have several limitations that makes them more difficult to service, including issues related to patching. Their content lives in a strange world where they are live in your MSI but stand apart from all other content in that MSI. They bulk up the size and slow down the performance of your MSI due to the way they integrate in (created system folder custom actions, difficulties in being referenced from your MSI-specific authoring, etc.). The closest build-style to merge modules on your list would be wixlibs (you can build and managed them the exact same way, without the merge module-specific pain). Or, you simply link in your projects to the source files wherever you place them for the shared fragment solution. One other thing superior with the wixlib/shared fragments approach over the MSM one is that any fragments you don't access in some way aren't included in the final link, meaning they don't take up any room in your MSI. That means you can always include all of them in all your projects, and just reference what you need. Merge modules, once built, are an all-or-nothing where simply including them includes everything in the MSM in your MSI, whether you really needed it or not. -----Original Message----- From: Thomas Due [mailto:thomas....@scanvaegt.dk] Sent: Thursday, October 22, 2009 11:45 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to best install generic system withcustomerspecific add-ins Fair enough, I'll try to explain the situation a little better, but Sascha's suggestion about shared fragments files makes absolute sense now that I think about it. It hadn't even crossed my mind. I would to be careful about how I shared them, so I would only have one actual copy of the fragments files, otherwise I would face hell updating all copies when there were changes to the common files. Anyway: I have a service with a couple of common libraries, in itself this service does nothing. It merely forms an extensible framework for customer specific functions. Then I have the customer specific functions, these are "just" dll assemblies which are added to the service and supplies the actual functionality. So, instead of having to copy-and-paste a generic WiX project to each customer project, I thought I would make a generic module which contains the service and common assemblies, the necessary functionality for installing and starting the service etc. Additionally it would contain the UI sequence but allow for customer specific dialogs. This module would then be added to a customer specific installer which contained the remaining logic, like adding the customer extension to the framework and other various customer specific actions. This is what I want, how do I do that best? Merge Modules? WiX libraries? Shared WiX fragments? Best regards, Thomas Due -----Original Message----- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 22. oktober 2009 17:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to best install generic system withcustomerspecific add-ins 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 ------------------------------------------------------------------------------ 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
