[wix-users] Split Existing Installer Into Two

[Edwin Castro]

There are no good answers here. Thinking out loud...

I hope the client is implemented as a separate feature tree from the proxy
and that none of those features share any components. This is where I would
begin. Make sure you understand your feature tree very well. Identify where
components go. If you have shared components, then you'll likely want to
split those shared components out to their own shared product.

Ideally, you'd want to detect the combined product to upgrade from both
separate products but you'd only want to upgrade if and only if specific
features were previously installed. You might need to write a few custom
actions to get that information but then you might be able to author launch
conditions to block upgrades that shouldn't happen.

Obviously, this all falls apart if you can have both client and proxy
features concurrently installed and they should both be installed post
upgrade. In this case the first product to upgrade will remove both
features from the old product. If there's no data loss, then this might be
simple. For example, if client upgrades need to be careful about data but
proxy upgrades are simple (remove old proxy and install new proxy) then
perhaps you can just allow the client msi to remove the complete combined
msi and use a bundle to install the client msi first before the proxy msi.
The bundle would need to look at feature states to decide which products
should be installed. Of course, you can simply reverse the order it it goes
the other way. If they both have fragile data management during upgrade...
then you're in a tough position. And if you've created a bundle, then
you're kind of back to where you started because you have a single thing
that can install both sets of bits but this time you have more complexity.

Lastly, understand that you will be dealing with multiple msi transactions.
Rollback is going to be difficult if not impossible. Given the difficulty
of rollback in the context of a single combined msi transitioning to
multiple msi products you may decide just to remove the existing product
individually first rather than allow the new msi to upgrade it.

[rant]
All that aside, I would really like to discourage you from "installing" a
msi in SystemA but that msi doesn't actually install resources on SystemA
but rather it installs resources on SystemB. I don't know what your proxy
is nor what "runs actions on remote devices" means but it sounds similar to
msi that install databases. Using the database scenario as a concrete
example, using an msi to install the database remotely rarely makes things
easier. When a sysadmin tries to figure what is installed on which systems
they find out that a system has a "database" msi installed but that system
doesn't actually have database software installed. The database is actually
installed someplace else. If somebody tries to upgrade the database from a
different system from where the database was originally installed, then it
looks like a clean install rather than an upgrade and ??? Perhaps the
terminology could lead to confusion, etc. If your proxy installs resources
locally but they are just a slim shim required locally to interact with a
remote system, then that is easier to deal with because you are really
installing something locally. If some of the motivation to splitting the
client and proxy in to separate msi is to better deal with such a situation
but you are still going to install remote resources using an msi on
different system then you're only addressing a small portion of the
problem. I'd encourage you to look into how to actually manage the "remote"
resources "locally" on the actual target system(s).
[/rant]

--
Edwin G. Castro


On Mon, Apr 27, 2020 at 2:19 PM Bryan Dam via wix-users <
wix-users at lists.wixtoolset.org> wrote:

> We have an existing installer that we are considering breaking out into
> two separate ones.  Why?  Because despite a shared codebase the
> configuration and use cases are very very different.  One acts as a client
> (runs actions on itself) while the other is a proxy (runs actions on remote
> devices).  Our customers appear to be confused by working through an
> installer that offers them both use cases and making the correct choices.
> Just the name of the MSI is cause for confusion ("It says Proxy but I want
> to install the client").  Further, since they do provide different
> functionality we envision situations where they are both installed (not
> currently possible).
>
> That being said, this sounds like a bad self-inflicted wound.
> Specifically: how do we upgrade the existing installs?  Which is to say,
> how do we handle the Product and Upgrade IDs?
> Would love to hear any suggestions the community might have or just
> general abuse for doing it wrong.  I wouldn't even blame you.
>
>          Thanks,
>                Bryan
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>