[wix-users] Uninstall of msi should trigger uninstall of bootstrapper

Edwin Castro egcastr at gmail.com
Sat Sep 15 22:28:16 PDT 2018 

That makes sense if, and only if, the bootstrapper basically does nothing.
In that case there's literally no point in having a bootstrapper in the
first place.

A general purpose chainer, like burn, can do a lot more, including running
other executables, all of it based on conditions on the target system that
we know can vary from system to system on any given enterprise. The
attitude that sys admins know better than the setup engineer that carefully
crafted a setup to handle seemlees upgrades from all kinds of screwed up
situations is just ridiculous. I hate it when those sys admins, and even
our own support engineers, take matters into their own hands. They nearly
always just make things worse.

But, yes, if the bootstrapper just installs an msi, then the bootstrapper
is pointless and shouldn't even exist. Assuming that is the only way to
install is naive though.

All of that aside, this host software has made the decision to only support
msi-based plugin installs. I think that is naive but whatever... no skin
off my back. I would recommend avoiding the bundle altogether because the
host software doesn't support it. If the plugin really truly needs a
bootstrapper/chainer, then they should really ask themselves why it is
necessary because the host software doesn't think it is necessary!
Otherwise they would support it. Or perhaps they never imagined a
legitimate scenario where one would be needed so they never designed for it
and they probably should be told of this legitimate use case. In any case,
if the host software doesn't support bootstrappers/chainers, then avoid
them.

All that said, I still do not understand why burn would decide to install a
package if the bundle is going to uninstalled. That doesn't make sense to
me and suggests that burn is doing that because it was told to do so. What
does the log say?

--
Edwin G. Castro



On Sat, Sep 15, 2018, 20:15 Walter Dexter <wfdexter at gmail.com> wrote:

> I’m just making stuff up on Saturday night after a morning of support, but
> enterprises generally don’t want bootstrappers because I don’t believe you
> can deploy them with SCCM/SCOM.
>
> Personally I just discard any bootstrapped our vendors provide and deploy
> the MSI, but I work in a very constrained environment. And the normal
> InstallShield setup.exe they hand off doesn’t seem to actually do anything.
>
> > On Sep 15, 2018, at 9:09 PM, Edwin Castro via wix-users <
> wix-users at lists.wixtoolset.org> wrote:
> >
> > <rant>
> > Just because "enterprise" software did it doesn't make it the right
> > approach. That enterprise software doesn't support anything that isn't
> msi
> > and, in my opinion, that was a mistake. You can and probably should tell
> > them that strategy was misguided. I agree that such actions are unlikely
> to
> > change anything but it doesn't mean it was good design.
> > </rant>
> >
> > My msi doesn't show up on Programs and Features. I didn't think I had
> done
> > anything explicit to get that behavior but perhaps I did. I'll need to
> > check the code to double check.
> >
> > You can certainly try to uninstall your bundle from your msi but I have a
> > feeling you're going to run into trouble as your msi is not done
> > uninstalling yet and, presumably, your bundle will try to uninstall other
> > msis, including possibly the msi that is still uninstalling. I don't know
> > for sure.
> >
> > Try it out. This isn't a "supported" use case. To me this backwards so it
> > makes sense that there isn't a "standard" way to do this. The correct
> > approach is to uninstall the bundle.
> >
> > That said, I can't believe that burn tries to uninstall the uninstalled
> msi
> > if you are trying to uninstall the bundle. Perhaps you are actually
> trying
> > to repair the bundle instead of uninstalling.
> >
> > --
> > Edwin G. Castro
> >
> >
> >> On Sat, Sep 15, 2018, 02:07 Farrukh Waheed <farrukh1 at gmail.com> wrote:
> >>
> >> Edwin,
> >> That software is an enterprise level software, and we are writing
> plugins
> >> for it. I personally can't suggest them to change their plugin
> deployment
> >> strategies. They are like our clients...
> >> They are handling msi's installation through their APIs. And I believe,
> >> they never considered the use of Bootstrapper/Burn in their plugin
> >> deployment scenarios.
> >>
> >> To understand this (default) behavior of Burn, install an msi, but let
> it
> >> appear in Programs & Features, so that you'll have 2 entries, 1 for your
> >> msi and 2nd for your Burn. Simply uninstall the msi first. After msi
> >> finished uninstalling, try to uninstall Burn and see its behavior... My
> >> custom bootstrapper would trigger a fresh Install if it doesn't find the
> >> installation of any of its chained msi's.
> >>
> >> I'm just looking for some method which would trigger the Burn's
> uninstall
> >> if msi is triggered to be installed. I may have to write a custom action
> >> for this, but seeking if there is some better alternative exists.
> >>
> >> Regards
> >>
> >>> On Sat, 15 Sep 2018 at 11:07, Edwin Castro <egcastr at gmail.com> wrote:
> >>>
> >>> Sounds like an implicit requirement of the host software is that
> plugins
> >>> be directly uninstallable only by an msi. If you can't convince the
> host
> >>> software to change that behavior to allow bootstrappers/chainers and/or
> >>> non-msi installers, then you might be forced to use a bare msi for the
> >>> plugin.
> >>>
> >>> Questions why does uninstalling the bundle when the msi has already
> been
> >>> uninstalled result in trying to install the msi again? I imagine,
> perhaps
> >>> incorrectly, that burn would decide to do nothing since you want to
> >>> uninstall and the package has already been uninstalled. Do you have a
> >>> launch condition that requires the host software be installed? If so,
> then
> >>> you can change that condition so that it doesn't fail when you are
> >>> uninstalling. You are still left with the bundle in Programs and
> Features
> >>> but at least you can clean up.
> >>>
> >>> --
> >>> Edwin G. Castro
> >>>
> >>> On Fri, Sep 14, 2018, 21:04 Farrukh Waheed via wix-users <
> >>> wix-users at lists.wixtoolset.org> wrote:
> >>>
> >>>> Hi Christopher,
> >>>> Even if msi is not visible in Programs & Features, it can still be
> >>>> uninstalled via "msi /x {GUID}" command line method. This doesn't
> trigger
> >>>> the uninstall of bootstrapper in any case... Our host software
> uninstalls
> >>>> its plugins using msi command line.
> >>>>
> >>>> On Sat, 15 Sep 2018 at 02:49, Christopher Painter <chrpai at iswix.com>
> >>>> wrote:
> >>>>
> >>>>> Generally you use ARPSYSTEMCOMPONENT   ( set via MsiPackage
> @Visible=No
> >>>>> element/attribute in your bundle ) to hide the MSI from Programs and
> >>>>> Features and only expose the bootstrapper.  This way the bootstrapper
> >>>> can
> >>>>> handle the package dependency relationships per your implemented
> >>>>> requirements.
> >>>>>
> >>>>>
> >>>>> ------------------------------
> >>>>> *From:* wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf
> >>>> of
> >>>>> Farrukh Waheed via wix-users <wix-users at lists.wixtoolset.org>
> >>>>> *Sent:* Friday, September 14, 2018 10:15 AM
> >>>>> *To:* WiX Toolset Users Mailing List
> >>>>> *Cc:* Farrukh Waheed
> >>>>> *Subject:* [wix-users] Uninstall of msi should trigger uninstall of
> >>>>> bootstrapper
> >>>>>
> >>>>> Hi,
> >>>>> I'm delivering a plugin (In chained msi in our custom bootrapper)
> for a
> >>>>> software. When the user uninstalls that software, it automatically
> >>>> triggers
> >>>>> the uninstall of its plugins (internally via Windows Installer
> Service
> >>>> i.e.
> >>>>> msi). But that leaves our Bootstrapper there in Control Panel. Now if
> >>>>> someone tries to uninstall it, bootstrapper would be asking to
> Install
> >>>>> itself (again) which would be failed as the parent software which
> will
> >>>> host
> >>>>> the plugin is not there.
> >>>>> Is there any event, which could trigger the uninstall of Bootstrapper
> >>>>> whenever the chained msi is triggered to uninstall?
> >>>>>
> >>>>> Thanks a bunch.
> >>>>> Farrukh
> >>>>>
> >>>>> ____________________________________________________________________
> >>>>> WiX Toolset Users Mailing List provided by FireGiant
> >>>>> http://www.firegiant.com/
> >>>>> WiX Support | WiX Experts and Resources from FireGiant
> >>>>> <http://www.firegiant.com/>
> >>>>> www.firegiant.com
> >>>>> WiX Support | Installation, Development, Deployment | WiX Experts and
> >>>>> Resources from FireGiant
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> ____________________________________________________________________
> >>>> WiX Toolset Users Mailing List provided by FireGiant
> >>>> http://www.firegiant.com/
> >>>>
> >>>
> >
> > ____________________________________________________________________
> > WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>

More information about the wix-users mailing list