You sounds a bit confused about merge modules. Think of them as source code; they're used when building your MSI, to include functionality defined by a third party. The merge module doesn't exist when you get to the machine on which you're installing you're MSI.
As a parallel, suppose I sent you a .c file which contained the code for a custom action; you'd build the .c into a Custom Action DLL and include and reference it in your MSI. When you run that MSI to install your product, the functionality described by my .c file gets used, but the .c file itself never gets anywhere near the installation machine. A merge module is conceptually similar. A different possibility is where you want to distribute a merge module as part of your product, to enable other people to build an MSI using the functionality you've defined in the merge module. In this case, the merge module is just a file which is part of your product, like any other, and would be installed as a file. If you need to put files on the installation system which are used as helpers of some sort during the installation, one way is to include them in a self-extracting archive which you execute as an executable custom action. I then use another customer action to delete them once they've been used. I believe a slightly more favoured way to do this sort of thing is to include the files as binary streams in the MSI and use custom actions to extract and manipulate them. It should only rarely be necessary to do this sort of thing, though. > -----Original Message----- > From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] > Sent: Tuesday, August 11, 2009 6:16 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] How to treat support files that do > not getinstalledontarget machine? > > > > Sorry. I was wondering what the normal practice would be > when you have > files that are utility files for the installation and not apart of the > application. They are not supposed to be installed, such as a merge > module. The msm doesn't get "installed" however it's content will be > installed. > > Thanks, > Jim > > -----Original Message----- > From: Pally Sandher [mailto:pally.sand...@iesve.com] > Sent: Tuesday, August 11, 2009 7:45 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] How to treat support files that do not > getinstalled ontarget machine? > > Your question is a bit vague (and contradictory). What do you > want to do > with these "support" files exactly? > > If they're required for your product then use a bootstrapper > to install > them before your product. Since you have a merge module for the XML > Parser simply merge it into your MSI using the Merge & > MergeRef nodes if > that's the case. > > Palbinder Sandher > Software Deployment & IT Administrator > T: +44 (0) 141 945 8500 > F: +44 (0) 141 945 8501 > > http://www.iesve.com > **Design, Simulate + Innovate with the <Virtual Environment>** > Integrated Environmental Solutions Limited. Registered in Scotland No. > SC151456 > Registered Office - Helix Building, West Of Scotland Science Park, > Glasgow G20 0SP Email Disclaimer > > > -----Original Message----- > From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] > Sent: 10 August 2009 20:08 > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] How to treat support files that do not get > installed ontarget machine? > > > I have some support files that I would like to include on the > installation disk. What's the typical practice for dealing with these > types of files that do not get installed? For example, I have a merge > module for the MS XML Parser that I want to call in my install. > > Thanks, > Jim > > > -------------------------------------------------------------- > ---------- > ------ > 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
