Add support for app/package Uninstall trigger

[JosHuybrighs]

I would like to raise a proposal to allow apps to register a background task that would trigger when a app/package is uninstalled.

The particular case where this would be mandatory for me is when I have a app that is forced to used Microsoft.Win32.TaskScheduler to register a TaskService that runs at a faster interval (a couple of minutes) than what is possible with the WinAppSDK provided TimeTrigger for a background task (min. 15 minutes).
I will need a Uninstall trigger then to remove the task from the task schedular when the app is being uninstalled.

Any thoughts on this? Or alternatives to achieve the same?

Allowing intervals less than 15 minutes for TimerTrigger'ed background tasks will of course be an even better solution for this particular case, but still I can imagine that there can be other cases where the above proposal would be helpfull.

[dhoehna]

@DrusTheAxe @jonwis @BenJKuhn

I believe that, as Windows App SDK evolves and ages, more people will want some kind of "Uninstall trigger", or "Do X at uninstall time." It'll behoof Windows App SDK to add hooks, or another technology to allow developers to run their own code at uninstall time.

[DrusTheAxe]

Thank you @JosHuybrighs and @dhoehna! Thoughts? Indeed :-)

We can add an uninstall-hook much like we do for install and update. This idea has bubbled around the team for a while so we have some thoughts on the subject. I'll write up a proposal (Issue).

The general thinking:

MSIX supports windows.preInstallConfigTask and windows.updateTask. The gaps / natural complements:

1. windows.uninstallConfigTask
2. ? windows.repairConfigTask
3. ? windows.resetConfigTask
4. Support non-UWP activations

windows.updateTask is a BackgroundTask activated when a package is updated for a user (e.g. user has v1.2.3.4 and 1.2.3.5 is registered). The deployment stack activates this when the package registration completes.

windows.uninstallConfigTask would need to be invoked by the deployment stack before the package is uninstalled. That poses some technical challenges that would have to be addressed e.g. must be time-boxed as an unbounded task could hang the uninstall for hours/days/ever.

Likewise, windows.repairConfigTask might be needed for repair scenarios. Might, as it may be reasonable to fire updateTask for a repair scenario (as in, if from/to versions are the same it's a 'repair' operation, if different it's an 'update').

Likewise, windows.resetConfigTask might be needed. Alternatively, as 'reset' is functionally equivalent to someone running the powershell commands Remove-AppxPackage + Add-AppxPackage merely running uninstall+install tasks before/after might suffice. Only problem there is MSIX currently has no windows.installConfigTask (windows.preInstallConfigTask only works for provisioned packages).

Another limitation today is BackgroundTasks only support UWP app activation. We'd want that to support non-Universal activation, and ideally one that works for both packaged and unpackaged apps.

@JosHuybrighs if this manifested-uninstall-task is run by the deployment stack when starting an uninstall operation and it would be a synchronous/blocking operation (deployment won't proceed to remove the package until the uninstall-task completed) would this meet your needs?

[JosHuybrighs]

@DrusTheAxe
Great! A synchronous/blocking operation will be OK for me. I expect that any de-registration that must be done will be fast.