[wix-devs] 6772 - ExePackage ARP entry

[Bob Arnson]

No change, just that we've suggested people avoid using InstallCondition to handle versioning logic when DetectCondition is sufficient. I see the logic, just feeling a little disturbance in the force...

> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Wednesday, 4 May, 2022 17:47
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] 6772 - ExePackage ARP entry
> 
> > I'm a bit...unsettled about overloading InstallCondition like that.
> > We've
> pushed against that in the past.
> 
> Am I missing something? I'm not changing any of the behavior of
> InstallCondition or DetectCondition or any other condition, that should be how
> it has always worked.
> 
> On Wed, May 4, 2022 at 4:42 PM Bob Arnson <bob at firegiant.com> wrote:
> 
> > > This will only install MyExe if it is missing or older.
> >
> > I'm a bit...unsettled about overloading InstallCondition like that.
> > We've pushed against that in the past.
> >
> > > With your example, the bundle would uninstall the MyExe package
> > > during uninstall if the installed version is greater than or equal to v1.2.3.
> > The package is
> >
> > Yes, that's intentional. I get why that might not be preferred, so I'm
> > fine with your proposed behavior, given that my scenario is still possible.
> >
> >
> >
> > > not Permanent. This new feature means that even though there are no
> > > UninstallArguments, it will still be uninstalled and since it uses
> > > the QuietUninstallString from ARP it should uninstall the newer
> > > version
> > instead of a
> > > no-op from the bundled .exe.
> > >
> > > On Wed, May 4, 2022 at 2:09 PM Bob Arnson via wix-devs < wix-
> > > devs at lists.wixtoolset.org> wrote:
> > >
> > > > > >  DetectCondition="MyExe_Version >= v1.2.3"
> > > > >
> > > > > The strict equals was intentional. If the installed version is
> > > > different, it is unlikely
> > > > > that the bundle should be uninstalling it.
> > > >
> > > > True but it usually would suffice for installation.
> > > >
> > > >
> > > > > > VersionVariable="MyExe_Version"
> > > > >
> > > > > This is redundant because it is the default value.
> > > >
> > > > I missed that. And I can't say I'm a fan. I can't think of any
> > > > other instances of that kind of default...other than log path variables.
> > > > Maybe that's enough precedent?
> > > >
> > > > > > If QuietUninstallString doesn't exist, should it fall back to
> > > > > UninstallString? Should the author be able to specify the value name?
> > > > >
> > > > > I was thinking maybe something like Quiet="yes/no". I'm not sure
> > > > > it's a
> > > > good
> > > > > idea to fallback to UninstallString, or maybe it's only OK
> > > > > during full
> > > > UI. Are there
> > > > > really installers out there that are writing uninstall strings
> > > > > to custom
> > > > value
> > > > > names?
> > > >
> > > > Probably not. QuietUninstallString isn't technically required, per
> > > > old certification guidelines; UninstallString is.
> > > >
> > > >
> > > > https://docs.microsoft.com/en-us/windows/win32/win_cert/certificat
> > > > ion-
> > > > requirements-for-windows-desktop-apps#5-apps-must-support-a-clean-
> > > > reve
> > > > rsible-installation
> > > >
> > > > Falling back would be polite but risky. I'm fine saying this is
> > > > for BundlePackage and other, well-behaved engines.
> > > >
> > > > >
> > > > > On Wed, May 4, 2022 at 1:03 PM Bob Arnson <bob at firegiant.com>
> wrote:
> > > > >
> > > > > > Very cool.
> > > > > >
> > > > > > The example should be something like this, no?
> > > > > >
> > > > > > <ExePackage Id="MyExe" SourceFile="my.exe"
> > > > > > DetectCondition="MyExe_Version >= v1.2.3">
> > > > > >     <ArpEntry Id="MyExeGuid" Win64="no"
> > > > > > VersionVariable="MyExe_Version" /> </ExePackage>
> > > > > >
> > > > > > If QuietUninstallString doesn't exist, should it fall back to
> > > > > > UninstallString? Should the author be able to specify the
> > > > > > value
> > name?
> > > > > >
> > > > > > I agree that running from a non-secure location isn't great.
> > > > > > Prohibiting it is probably the safest choice...otoh, it's
> > > > > > probably a common case (e.g., Squirrel).
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On
> > > > > > Behalf Of Sean Hall via wix-devs
> > > > > > Sent: Wednesday, 4 May, 2022 13:44
> > > > > > To: WiX Toolset Developer Mailing List
> > > > > > <wix-devs at lists.wixtoolset.org>
> > > > > > Cc: Sean Hall <r.sean.hall at gmail.com>
> > > > > > Subject: [wix-devs] 6772 - ExePackage ARP entry
> > > > > >
> > > > > > I wrote up a WIP on using an ARP entry to help detect and
> > > > > > uninstall an ExePackage -
> > > > > > https://wixtoolset.org/development/wips/6772-exepackage-arp-entry.
> > > > > > Any feedback?
> > > > > >
> > > > >
> > >
> _________________________________________________________________
> > > > > ___
> > > > > > WiX Toolset Developer Mailing List provided by FireGiant
> > > > > > http://www.firegiant.com/
> > > > > >
> > > > >
> > >
> _________________________________________________________________
> > > > > ___
> > > > > WiX Toolset Developer Mailing List provided by FireGiant
> > > > > http://www.firegiant.com/
> > > >
> > >
> _________________________________________________________________
> > > ___
> > > > WiX Toolset Developer Mailing List provided by FireGiant
> > > > http://www.firegiant.com/
> > > >
> > >
> _________________________________________________________________
> > > ___
> > > WiX Toolset Developer Mailing List provided by FireGiant
> > > http://www.firegiant.com/
> >
> _________________________________________________________________
> ___
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/