[wix-users] Split Existing Installer Into Two

[Edwin Castro]

If you want possibly to install both proxy and client together on the same
system later in the future, then you're going to want to install your
files to different directories. Otherwise you have shared components for
the files.

You can most definitely give one of the new MSIs a new upgrade code and
also add the old upgrade code to allow seamless upgrades from the old to
the new. Note that if the other new MSI shares the old upgrade code, then
you'll also be allowing seamless upgrades from client to proxy or vice
versa depending on which one shares the old upgrade code. That also makes
installing both proxy and client side-by-side harder in the future. You
probably want both client and proxy to have new upgrade codes so they don't
upgrade each other. Both should include the old upgrade code in the upgrade
table to allow seamless upgrade from the combined msi. Both should likely
detect the other new upgrade code so that you can implement a
launch condition to disallow side-by-side installations until you're ready
to support that case. And you should still install your files to two
different directories so those files are not shared components so that all
you likely need to do later to support side-by-side installations is to
simply remove the launch conditions. Your files would be duplicated on that
side-by-side installation but that makes both of them easier to manage.

--
Edwin G. Castro

On Tue, Apr 28, 2020 at 5:30 AM Bryan Dam <bryand at recastsoftware.com> wrote:

> Re-read your response Edwin and think I can add some additional
> clarification.
>
> Right now installing both the client and proxy installed isn't possible so
> that's not an upgrade scenario we're worried about for this transition.
> Neither install type has any data stored locally either that we need to
> worry about.  I can also confirm that this is not the SystemA and SystemB
> scenario.  The whole 'proxy does remote things': the proxy type configures
> the installed service with a service account that needs to be local admin
> on remote devices so that is has permissions to make remote calls to
> registry/WMI/admin shares.
>
> My initial thought was to just split the installer, and keep the same
> upgrade code.  We exclusively do major upgrades so while that would allow
> users to install one type/install over the other that's not the biggest
> problem in the world.  However, though it's an edge case where you'd want
> both a proxy and a client installed it's one we'd like to support I guess.
> So that nixes that idea.  I think what I'm looking to do is create a new
> upgrade code for one of the install types but for the next few releases
> still tie that to the existing upgrade code so that the old version
> uninstalls itself.  That's probably fools-gold but conceptually that's the
> idea.  I think.
>
>             Thanks again,
>                  Bryan
>
> -----Original Message-----
> From: wix-users <wix-users-bounces at lists.wixtoolset.org> On Behalf Of
> Bryan Dam via wix-users
> Sent: Monday, April 27, 2020 10:38 PM
> To: Edwin Castro <egcastr at gmail.com>; 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
>
> 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/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>