Desktop-Bridge app: Remove from Task Scheduler when uninstalled

Question

I have a UWP - Desktop Bridge app (published on the Windows Store) which I want to extend with the possibility to run the win32 process through the Windows Task Scheduler (at a configurable time).
To add and modifying an entry in the task scheduler I suppose that I can simply launch the win32 process and interact with the scheduler from there.
The issue I really have is that I don't see any possibility to remove the scheduler entry when the user uninstalls the app. As far as I know there is no trigger coming into my desktop app when it is being uninstalled.

Any suggestions about this?

Answer 1

In general you should move from Scheduled Tasks to BackgroundTasks and Triggers. You many need to add a UWP process to your package to handle the types of Triggers you want (ie: TimeTrigger). Note that we are adding support in Windows 10 (2004) for PushNotificationTriggers from a fulltrust Win32 process, and we would like feedback on which additional triggers developers would be interested in.

For completeness, if you need to stay with a ScheduledTask, you can mitigate part of the issue when the app is running by subscribing to the PackgeUninstalling event and do clean up. If the app is not running, there is no solution.

Answer 2

@Adam Braden [MS]

Adam,

OK, then it is best to stay with my current implementation where the UWP part in the package (actually the part that runs at startup) has an in-process background task that runs every 15 minutes and, when necessary (typically once in a day) launches the win32 process to run a possibly long-lasting folder sync/backup task.

PushNotificationTriggers could be an interesting concept if it would allow my win32 process to pass notifications to the UWP (GUI) part at any point in time. In my current implementation the win32 process can run longer then the allowed lifetime of the UWP (GUI) part of the app (25..30 seconds). If it would be possible to pass notifications from the win32 process to a new instance of the UWP process then that would of course be an advantage. Today I communicate notifications between both processes using LocalSettings.

Answer 3

Have you taken a look at ExtendedExecution? I'm not sure if that will fit your needs for a long running background task and the fileio you need.

Regarding IPC, I wouldn't recommend PushNotifications - that is for activating your app through various cloud triggers. Typically you can use AppServices if you do not need a high bandwidth channel. This blog shows an example of using that between a UWP and Win32 fulltrust process.

Adam

Answer 4

The app is SyncFolder (on the store) and the reasons of coming up with a win32 process for doing the actual copying/deleting of files and folders were:

• Full access to hidden folders/files in both the source and target location.
• Extended execution was (still is?) a no-go at that point in time to get the app in the Windows Store.

I am actually using AppServices when the win32 process is launched to communicate the task that is due to the win32 process. But since the background task scheduler that runs in the UWP app (using TimeTrigger) will be killed after half a minute (there is no UI active) the only way to communicate status information to the app when it is started at a given time by the user is by using LocalSettings.

An interesting feature by the way for these kind of problems would be to allow a win32 process in that case to be the listener for an AppServiceConnection instead of a client. But that is for probably good reasons not possible.

I am aware that with the latest Windows releases (XAML islands, etc..) starting from a win32 app and build from there the UI would have been a better approach.