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

Sat Sep 15 20:14:58 PDT 2018

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/