[wix-devs] 5950 - Rollback ExePackage on cancel

[Sean Hall]

> I should have guessed that first.

To be fair, your logic could have been implemented earlier by incorporating
both the Permanent and UninstallArguments attributes when it was parsing
the manifest.

> I think it also says a DetectCondition is necessary unless the ExePackage
is Permanent. I should probably update the compiler logic to that instead
of keying off UninstallArguments. I'll do that.

That sounds good, thanks.

> But maybe it just isn't a real issue. Maybe we just expect non-installed
ExePackage's uninstall to be a no-op

I don't think we should worry about this. The expectation should be that
people creating ExePackage's will make their uninstall behavior the
opposite of the install behavior. If people want uninstall to do completely
different things than install, then it should be two separate packages. I'm
pretty sure you could setup an uninstall-only ExePackage.

There is a real issue with ExePackage's though. We abandon waiting for the
process to exit when the BA cancels. We would probably need to add a way
for the BA to opt-in to waiting for the process to exit in order to be able
to do the rollback action.

On Mon, Jan 18, 2021 at 8:23 AM Rob Mensching <rob at firegiant.com> wrote:

> > You are not recalling correctly. Burn doesn't use UninstallArguments for
> anything other than building the uninstall command line.
>
> Well, that is simpler and it does align with the original Burn design of
> doing as little calculation during execution as possible. I should have
> guessed that first.
>
>
> > Which means requiring a DetectCondition when UninstallArguments are
> provided doesn't help here.
>
> Indeed. I think it also says a DetectCondition is necessary unless the
> ExePackage is Permanent. I should probably update the compiler logic to
> that instead of keying off UninstallArguments. I'll do that.
>
>
> > The bug for 5950 is specifically that the rollback action isn't executed
> for an ExePackage when it fails.
>
> Yes, understood. Specifically, my concern is uninstalling an ExePackage
> during the rollback (of an install execution) after it was not successfully
> uninstalled. Doing so means that ExePackage uninstalls are a no-op when
> they are not installed. We know that uninstall of MsiPackage's that are not
> installed is a no-op (explicit error code, ERROR_UNKNOWN_PRODUCT, IIRC).
>
> But maybe it just isn't a real issue. Maybe we just expect non-installed
> ExePackage's uninstall to be a no-op and fix 5950 to make everything behave
> like MsiPackage.
>
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Sunday, January 17, 2021 1:10 PM
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: [wix-devs] 5950 - Rollback ExePackage on cancel
>
> I changed the title since I originally only mentioned 5950 to provide
> context for my questions about 6297.
>
> >  IIRC, no uninstall arguments means ExePackage is not uninstallable
>
> You are not recalling correctly. Burn doesn't use UninstallArguments for
> anything other than building the uninstall command line. The documentation
> even calls out: "If this attribute is absent the executable will be
> launched with no command-line arguments".
>
> Which means requiring a DetectCondition when UninstallArguments are
> provided doesn't help here. This is actually a bug today, Burn never should
> have tried to schedule a rollback action of uninstall if there was no
> DetectCondition.
>
> > I don't have a good solution to this problem and I'm still wary of
> running uninstall on a ExePackage if it wasn't detected.
>
> The bug for 5950 is specifically that the rollback action isn't executed
> for an ExePackage when it fails. The rollback action would be executed if a
> later package failed (assuming no RollbackBoundary between them). Are you
> suggesting that we never schedule rollback actions for ExePackages? Or just
> in the case where the execute action is Install and the rollback action is
> Uninstall? I'll mention it again, MsiPackage always schedules the rollback
> action such that it will be executed during rollback even if the package
> had failed. It does this for execute=Uninstall and rollback=Install, and
> all other combinations of actions.
>