[wix-users] Help with MSM including in MSI

Fri Apr 16 13:34:57 PDT 2021

We used to build an unclassified version of a product, a secret and a top secret version of a product.  Sometimes the product MSI grew at each level and sometimes it was like a wedding cake where a product MSI existed at each level and was chained together.   This had no impact on merge modules as it was just a matter of how we consumed the merge modules into the product installers.  The approach we took depended on whether the different layers always added to the previous layer or whether the layers replaced implementations of functionality from a previous layer.

If your software is loosely coupled and uses dependency injection it becomes very easy to think in terms of this is a tree of related assets independent of product.  A product is just a view of that configured and branded in a certain manner.  How you break that all out into merge modules or wixlibs is just an exercise in set theory and normalization.

We the installation experts  were responsible for the overall architecture and explaining the patterns to the  developers.  They were then responsible for managing which files were included in which merge modules.  If they were ever any questions, we were available to consult.

________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Rob Mensching via wix-users <wix-users at lists.wixtoolset.org>
Sent: Friday, April 16, 2021 12:42 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>; Miles Davies <Miles.Davies at horiba.com>
Cc: Rob Mensching <rob at firegiant.com>
Subject: Re: [wix-users] Help with MSM including in MSI

> 2. Is built/compiled within one of the several said installations/projects, rather than built on it's own build plan

Either of those options are reasonable. Picking one will be based on organization tradeoffs.

> 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.

I like teams owning their installation logic (that was one of the key features of the WiX Toolset) but there do need to be checks by "installation experts" in the system. Custom actions are a good example of something that should (pretty much) always be managed by the "installation experts".

> 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)?

No. That's a very reasonable design option. For example, we (FireGiant) have designed a couple systems with strategically organized packages to minimize restart potential. Larger systems often end up with more organizational boundaries. Or sometimes a single MSI is desirable.

The WiX Toolset scales to meet these varied requirements.

-----Original Message-----
From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of John Zajac via wix-users
Sent: Friday, April 16, 2021 10:28 AM
To: Miles Davies <Miles.Davies at horiba.com>
Cc: John Zajac <jzajac2 at gmail.com>; WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Subject: Re: [wix-users] Help with MSM including in MSI

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

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/