[wix-users] Split Existing Installer Into Two

[Bryan Dam]

Thanks for the response Edwin.  I’ll read over a bunch of times tomorrow to try and full digest it.

In our case there’s no components or features.  The only difference between the client and proxy is ultimately that the client runs the service as Local System and the proxy runs it as a specified service account.  That’s really it.  That’s truly the only difference: what account is used to start the service.  The binaries are exactly, bit-for-bit, the same.  Which is why we initially made just one installer: this is purely a configuration issue.  We’ve just found that having this choice in the installer itself has confused our customers so the question was asked: what if they were separate.

        Thanks,
            Bryan

From: Edwin Castro <egcastr at gmail.com>
Sent: Monday, April 27, 2020 8:12 PM
To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
Cc: Bryan Dam <bryand at recastsoftware.com>
Subject: Re: [wix-users] Split Existing Installer Into Two

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<mailto: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/