[wix-users] Help with MSM including in MSI

Sun Apr 11 09:40:40 PDT 2021

About 10-13 years ago I was responsible for dozens of installers for a company's $70m/year product line.  Think along the lines of MSFT DevDiv where different assets from the product line, business domains and finally product specific code at multiple security classification levels were combined in various combinations to create installers as complex as Visual Studio yet varied similar to an auto manufacturer offering different .  A product typically consisted of bootstrapper around 5gb with many third party middleware and supporting applications and a main product installer with around 200 features from 20 service families and 2000 merge modules and 20,000 files.    The idea was for a product owner to be easily able to select the features and variation points needed from the product line and add some custom code to create a new product.

Yes, most merge modules were component and resource data.  It was basically a big exercise in set theory and normalization.  But there were also merge modules that implemented other things such as AppSearches and custom actions.  There were other merge modules that implemented custom tables to be married up with those custom actions.  Other merge modules simply set properties.  The idea was to avoid code redundancy.

We used a single InstallShield Basic MSI called the "common installer" to bring all this together.  Everything in the common installer was carefully designed to be generic and property driven and dynamically extended from there at build time.  For example, there was no feature tree in this installer.  Custom code would parse WiX XML files from the various service families to build the feature tree and merge module relationships as well as create the Product Configuration and release flags to bring the rights sets of features into the build and the correct ProductName, INSTALLDIR and UpgradeCodes.  By controlling which merge modules were consumed properties would enable things such as SQLLogin dialogs and AppSearch/LaunchConditions,  data driven transactional custom actions and the related table data to drive them per that product's needs.

It'd takes a few hours to describe it past this but basically the system was very reliable and easy to manage.   We created a custom WiX UI and taught all the developers how to update their own merge modules and reduced the install team from 6 resources to 2 resources (so the other could take vacation time).  Our backlog was reduced from 100 issues to about 5 issues and average cycle time from 3 weeks to 1 day.  We could attend meetings and help drive the design of applications to be installer friendly instead of always being reactive.  Our testers and product owners no longer struggled.

So yes, I'm kind of a huge fan of merge modules for internal use when the scenario calls for it.  Most of my installers these days only have 1-2 features with 1-2 merge modules, but I know my designs scale way past that if I ever need it.  I stay in a WiX ecosystem and yes it takes a little longer to build an installer with merge modules rather than wixlibs but it's usually not a concern.  If it is, such as an Electron app with 80,000 files in its packages directory,  then I'll use heat to author a fragment inside the MSI project to speed that up.   I'll typically exclude the main EXE and still author that inside the merge module just because my tooling makes it so easy to.

________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of John Zajac via wix-users <wix-users at lists.wixtoolset.org>
Sent: Sunday, April 11, 2021 10:22 AM
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/