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

Sun Sep 16 16:01:21 PDT 2018

SCOM is a monitoring solution.  SCCM can do EXE no problem.  You can create a package/program or you can use Application Model.  MSI is better but not everything fits in the box that is MSI.

Now there are reasons to not use a boostrapper in SCCM.  For example it can be more advantageous to have say .NET 4.7.2 in it's own package with 50 other packages having a dependency on it.  It's more normalized and you get better logging/metrics/visibility that way  rather then   50 packages call having a setup.exe that installs who knows what.  But it also takes more work in SCCM to set this up and there's no way your going to take something massive like Visual Studio and break it down into it's micropackages and reinvent all that glue in SCCM.

I also agree with the previous notion that it's generally not OK to do something a  certain way just because it's internally used in an enterprise and not distributed to others as shrinkwrapped sotware.   There are exceptions to that though.     I call this Product vs System.  If I'm building a Product I follow all the rules.  If I  am  building a System  then I allow some of the rules to be ignored  to meet the needs of the client for that system.   However  when I break the rules  I do it as cleanly as possible.   For example if someone tells me  "Requirement:  The installer should default to  D:\Apps\Name    I won't hard code this into the directory table.  I'll write a custom action that sets the install location to that path  if it's valid, if it's not already installed and if a path wasn't passed at the command line.       If I test on a VM with no D:\  drive then it'll still default to [ProgramFilesFolder]Company\Product.

That's my take on all this. I hope it helps and I'm open to further discussion if you want to tease out any more detail.

________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Walter Dexter via wix-users <wix-users at lists.wixtoolset.org>
Sent: Saturday, September 15, 2018 10:14 PM
To: WiX Toolset Users Mailing List
Cc: Walter Dexter
Subject: Re: [wix-users] Uninstall of msi should trigger uninstall of bootstrapper

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

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/