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

[Edwin Castro]

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