Christopher,
Thanks for explanation. This demystifies the MSM a lot.
But I still get one open question. When the merge module is used, I add
a <MergeRef> to the Feature section and a <Merge> to the Directory
section where the files from the module should be installed. If the
merge module has a <DirectoryRef> to "MergeRedirectFolder" then this
reference is resolved as the directory determined by the location of
<Merge>.
So when I want to add two tools to a product with this directory tree:
PogramFilesFolder
Company
Product
ToolA
ToolB
I can build the directory structure in the Products wxs file and place
the <Merge>s to the appropriate location.
The tools can also be used as stand-alone programs, what requires in
addition to the wixlib files a .wxs that builds the tool installer. I
wouldn't care about the install location and name it INSTALLLOCATION in
that case. Do I have to use global unique names for the DirectoryRef in
the wixlibs to make it reusable or can I redirect this somehow in the
.wxs files where I refer the wixlibs?
Andy
Am 24.12.2011 14:34, schrieb Christopher Painter:
> What you are calling a "common componet" is called a "shared component" in
> all of the MSDN docs. A merge module is merely an MSI database that
> serves as an encapsulation of a collection of globally unique components.
> A merge module with have information like directories, files, registry,
> shortcuts, services but it won't have any information related to features
> or products. You associate a merge module to one or more features in your
> product ( one of them is considered primary ) and merge the MSM into the
> MSI at build time so that all of the components in that module get
> associated ( FeatureComponents table ) to the features in the MSI. Once
> this is done the merge module is no longer needed and doesn't exist in the
> MSI. In otherwords the merge module doesn't get "installed" as if it's
> some object with a .Install() method.
>
>
> Merge modules were the original technique that Microsoft came up with to
> package up a shared component and reuse it with multiple MSIs. It is still
> needed to share components with MSIs written with different tools.
> However, if you are staying in a WiX only world, you can use other
> techniques such as fragments and libraries to do this within WiX at the
> source and linker layers prior to generating MSIs.
>
> ----------------------------------------
>
> From: "Andreas"<andreassand...@gmx.net>
>
> Sent: Saturday, December 24, 2011 4:03 AM
>
> To: wix-users@lists.sourceforge.net
>
> Subject: Re: [WiX-users] Cascading Merge Modules
>
>
> David,
>
>
> Thanks for your reply. I always thought that MSM is used for a "common
>
> component" that can be installed from different MSI installers. The
>
> "common component" should be uninstalled when the last MSI is unstalled
>
> using a kind of reference management.
>
>
> Your proposal uses a different approach. The wixlib adds some components
>
> to the MSI that are installed as like it is a part of the product
>
> itself. I gave it a try and it works. Obviously the reference management
>
> is performed on component level not on any kind of merge module level.
>
> - Can you confirm this?
>
> - Is the MSM completely integrated in the MSI file and does it give no
>
> kind of "grouping", "isolation of any kind" or so?
>
>
> So I assume I would only use MSM when I have to cooperate with an
>
> installer tool other that WiX.
>
>
> Andy
>
>
> Am 23.12.2011 15:10, schrieb David Watson:
>
>> Hi,
>
>> You only need to use merge modules if you want to supply them to third
>
>> parties for use in their installations that do not use wix.
>
>> If you do not have this requirement then you can split your installer up
> to
>
>> use a Base and tool wixlib when then can be linked into the tool and
> product
>
>> MSIs. Think of a wixlib as a c static linked library, you would have two
>
>> separate ones and link them both into the resultant MSI.
>
>>
>
>> You can also have several wix fragments and build each MSI from combining
> the
>
>> appropriate source files without bothering with a wixlib.
>
>>
>
>> Dave
>
>>
>
>> -----Original Message-----
>
>> From: Andreas [mailto:andreassand...@gmx.net]
>
>> Sent: 23 December 2011 13:42
>
>> To: wix-users@lists.sourceforge.net
>
>> Subject: [WiX-users] Cascading Merg Modules
>
>>
>
>> I have a question about design of installer and merge modules.
>
>> I have a COM server as base component. This is reusable and must be used
>
>> a by a tool. Further this tool may be part of a product.
>
>>
>
>> BaseComponent + Tool -> ToolInstaller
>
>> BaseComponent + Tool + Application -> ProductInstaller
>
>>
>
>> I want to design the best set of WiX projects. Since the base component
>
>> is reusable it should be implemented with a merge module, shouldn't it?
>
>> When I build the tool installer I will use a WiX product project to
>
>> generate a MSI file. But how should I integrate the tool installation in
>
>> the product? One solution would be a tool merge module. But does the
>
>> product always have to add the tool merge module and the base component
>
>> merge module. Or can I design the tool merge module to "include" the
>
>> base component?
>
>>
>
>> How can a wix library help here?
>
>>
>
>>
>
>>
> ----------------------------------------------------------------------------
> -
>
>> -
>
>> Write once. Port to many.
>
>> Get the SDK and tools to simplify cross-platform app development. Create
>
>> new or port existing apps to sell to consumers worldwide. Explore the
>
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>
>> http://p.sf.net/sfu/intel-appdev
>
>> _______________________________________________
>
>> WiX-users mailing list
>
>> WiX-users@lists.sourceforge.net
>
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>> SDL PLC confidential, all rights reserved.
>
>> If you are not the intended recipient of this mail SDL requests and
> requires that you delete it without acting upon or copying any of its
> contents, and we further request that you advise us.
>
>> SDL PLC is a public limited company registered in England and Wales.
> Registered number: 02675207.
>
>> Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire
> SL6 7DY, UK.
>
>>
>
>>
>
>>
> ----------------------------------------------------------------------------
> --
>
>> Write once. Port to many.
>
>> Get the SDK and tools to simplify cross-platform app development. Create
>
>> new or port existing apps to sell to consumers worldwide. Explore the
>
>> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>
>> http://p.sf.net/sfu/intel-appdev
>
>
> ----------------------------------------------------------------------------
> --
>
> Write once. Port to many.
>
> Get the SDK and tools to simplify cross-platform app development. Create
>
> new or port existing apps to sell to consumers worldwide. Explore the
>
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
>
> http://p.sf.net/sfu/intel-appdev
>
> _______________________________________________
>
> WiX-users mailing list
>
> WiX-users@lists.sourceforge.net
>
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> ------------------------------------------------------------------------------
> Write once. Port to many.
> Get the SDK and tools to simplify cross-platform app development. Create
> new or port existing apps to sell to consumers worldwide. Explore the
> Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
> http://p.sf.net/sfu/intel-appdev
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
