[wix-users] Help with MSM including in MSI

Fri Apr 16 10:27:32 PDT 2021

I'll share what I can:
I am dealing with a merge module which:
1. Has components/files (I'm fine with that one however), custom actions
(and no, not just the type51's... but medium complexity in behavior using
DTF/c#.net), xmlconfig/xmlfile actions, installs a *windows service* which
is shared/used across *several *other product installations that may or may
not be also installed on end users system, and is installed into
ProgramFiles/CommonFiles/[companyName]/etc. I'm sure there's even more
tables / msm features being used that I'm not listing, but the ones I'm
listing stand out to me the most. And of course there is also the property
value passing from the MSM to the MSI for *crucial* behavior to work right
- if it didn't work right the application wouldn't work (as it sets a
config file value).
2. Is built/compiled within one of the several said installations/projects,
rather than built on it's own build plan
3. And after some questioning about why this design decision, I am told
that it was once heavily disputed that this^ was the correct, appropriate
way to do it.

Am I crazy to think that maybe one better way to handle this is with a
separate project/installation package, and further to optimize for user
experience - either chained with each consuming product's MSI (less ideal
for me) or bundled into a bootstrapper (more ideal)?

By the way, the way i'm approaching some greenfield work for consolidating
multiple product installs into one single install, is with a bootstrapper
project, wixlibs and/or merge modules which *only *have Components and
Files (in case they come back say - oh just kidding we also want individual
installers available, too), and hoping to have the time to make the UX
(minus the branding of course) be kind of like the resharper installer (I
am in love with how they did that).

On Fri, Apr 16, 2021 at 8:21 AM Miles Davies <Miles.Davies at horiba.com>
wrote:

> Hi John,
>         There are many ways to skin a cat I guess.
>
> My experience of merge modules is tainted perhaps by experience of
> Microsoft Windows Installer projects (vdproj) generating merge modules with
> overlapping contents. With a good design and tooling and a decoupled
> architecture anything seems simple.
>
> I wouldn't push one solution over another but I think Rob's view point
> holds true for me too.
>
> 1) If you are entirely in a WiX echo system then stick with WiX libs.
> 2) If you are in a cross installer echo system then as long as your output
> merge module can be consumed then you could still generate it from multiple
> WiX Libs. You wouldn't be driven to use merge modules even in this case.
> 3) If you have multiple components that you cherry pick into multiple
> products then maybe a merge module approach works best.
>
>  The Windows Installer tooling we use to generate merge modules currently
> generates horrible merge modules with multiple instances of the same
> dependencies being installed as unique components. This is the hell I live
> in and why I would advise against merge modules generally. In my view they
> add a level of complexity that can be avoided if they are not needed. Seems
> your great design and tooling removes those issues.
>
> Care to share?
>
> Best regards,
>         Miles
>
> -----Original Message-----
> From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of
> John Zajac via wix-users
> Sent: 11 April 2021 16:22
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Cc: John Zajac <jzajac2 at gmail.com>
> Subject: Re: [wix-users] Help with MSM including in MSI
>
> Also, in my experience, using merge modules internally / only to your
> organization but also for purposes of sharing 'behavior', if you will, such
> as custom actions and setting up config files - activities where your merge
> module would need a CustomAction table in your merge module the consuming
> MSI may need to also pass property values/parameters to - could be
> nightmarish.
>
> Be curious to hear what others (Chris?) think about that. I'm tempted to
> hold onto a strong opinion: that merge modules should 1) be internal to an
> organization as a way of sharing and 2) limited to tables like components,
> files, dirs, resources and stay away from putting in behavior such as
> custom actions
>
> re: "I do shy away from using merge modules in the third party sense
> because there have been so many poorly authored merge modules that
> consuming them often introduces problems into your own MSI.  For these I
> prefer  EXE/MSI redists and chaining them using Burn."
>
> So in my current case where an internal merge module is shared across
> multiple products and that has several XmlConfig, CustomAction tables -
> behavior stuff - would be better off either A) having the behavior in the
> merge modules extracted and have it's consuming MSI responsible for or B)
> having it be it's own MSI instead and wrap them with a burn EXE.
>
>
> On Thu, Apr 8, 2021 at 12:33 PM Christopher Painter via wix-users <
> wix-users at lists.wixtoolset.org> wrote:
>
> > Hi Miles,
> >
> >  Remember that MSI predates WiX.  Merge Modules absolutely can be used
> > as libraries to build a larger installer.  That's what my tool IsWiX is
> all
> > based on.   Merge modules can be useful because you can author them using
> > WiX and consume them using InstallShield as an example. WiX then came
> > along and created it's fragment and wixlib patterns to streamline all
> > of that and eliminate some complexities associated with merge modules
> > but this assumes you are staying in an all WiX ecosystem.
> >
> >  I do shy away from using merge modules in the third party sense
> > because there have been so many poorly authored merge modules that
> > consuming them often introduces problems into your own MSI.  For these
> > I prefer  EXE/MSI redists and chaining them using Burn.
> >
> >
> > As to the original question of how do you "convert" an MSI to an MSM...
> > you don't really.   MSI has concept of Product, UI, Features,
> Installation
> > directory and so on.  Merge modules are more abstract.  They have
> > module signature,  sub directories, components, resources but none of
> > the other previously mentioned meta that an MSI has.
> >
> > Regards,
> > Chris
> >
> > -----Original Message-----
> > From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of
> > Miles Davies via wix-users
> > Sent: Thursday, April 8, 2021 8:08 AM
> > To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> > Cc: Miles Davies <Miles.Davies at horiba.com>
> > Subject: Re: [wix-users] Help with MSM including in MSI
> >
> > Hi Pavel,
> >         I wonder if I might ask why? This would seem an odd thing to
> > do, at least as far as my understanding goes.
> >
> > MSM files are Windows installer 'merge modules' which are intended to
> > be distributed by themselves. The merge module is then used by
> > external parties to include into their own installers. An example
> > might be a library or tool such as the Microsoft CRT re-distributable.
> > Merge modules are not designed as a 'library' container to build a
> > larger installer from. That would be more closely mirrored by a WiX
> library.
> >
> > In terms of installing a set of MSM files for an external user to
> > consume in their own installers you wouldn't want to unpack them in
> > your MSI but xcopy them into a known location.
> >
> > I can help with creating a MSM and consuming it from an MSI but I am
> > not really sure that is what you want.
> >
> > Best regards,
> >         Miles
> >
> > -----Original Message-----
> > From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of
> > Pa via wix-users
> > Sent: 05 April 2021 17:03
> > To: wix-users at lists.wixtoolset.org
> > Cc: pavel.zelenko at ktp.solutions
> > Subject: [wix-users] Help with MSM including in MSI
> >
> > Guys, can someone help me by providing full example of converting .MSI
> > to .MSM and include these newly created .MSM into another .MSI
> >
> > The sample or example will be helpful
> >
> > Thanks in advance
> >
> >
> >
> >
> >
> >
> >
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
>
>
> --
> -John
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>

-- 
-John