Does Windows App SDK need better support for periodic background tasks?

[JosHuybrighs]

I am porting my SyncFolder UWP/Desktop-Bridge app to a WinUI 3 - Desktop app (using Windows App SDK 1.0 and a package/wap project).
My app allows users to configure sync/backup tasks for selected folders and target devices and allows users to automatically schedule these tasks using a configured time schedule.
In the current UWP/DesktopBridge version the scheduling occurs with a UWP timer-triggered background task, which every 15 minutes checks whether a task is due and if so launches a win32 project to do the actual copying/syncing.
The win32 process uses a AppService Connection to communicate status and progress with the UI user-app in case the user would have opened the app.
With WinUI3-Desktop I can finally get rid of the unreliable AppService Connection because it allows me to have a single app/process that can both show the UI when necessary or run hidden and execute the sync/backup tasks when triggered in the background.

The challenge with Windows App SDK now is: which concept to use for running a periodic task?
There seems to be 3 possible approaches, but none of them offers enough capabilities.

1. Timer-triggered background task, as it is done in UWP.
   Today this requires an OOP background task and, if you follow the description I gave in an earlier discussions topic #2314, is not so difficult to do.
   The major problem however with this concept is that such a task doesn't run while the screen is in lock state. That is not ideal for the kind of app I am publishing.

2. A startup-task that periodically executes code.
   Such task would be added to the package and will do whatever it needs to do (check if sync/copy tasks are due in my case), wait 15 minutes, check again. It will keep on doing this until the task gets killed.
   This is relatively simple to implement using Application.Run(context) in a windows forms project (without an active window) and a Timer that fires every 15 minutes. It also seems to allow that execution keeps on occurring while in the lock screen.
   2 problems however with this:

• The process uses computer resources permanently.
• When updating the app the deployment/provisioning service in Windows kills the startup-task, which generates an error in the windows event log saying that the process hangs. I tried to hook up the WM_CLOSE message but it look like this message isn't dispatched when the app gets killed by the Windows deployment service.

3. Register the app with the Windows Task Schedular.
   That seems to be the ideal solution since it allows execution to happen in all kind of circumstances, like in lock screen, force to go out of sleep state, etc.
   The major issue however with this is that there is no possibility to deregister the app from the Task Schedular when the app is uninstalled.
   Windows App SDK supports a UpdateTask (to support app updates) but there is no "UninstallTask".
   Maybe of interest: there is an issues topic #16 that discusses the need to support 'uninstall' in the MSIX manifest and support for a Uninstall-task.

I am interested to learn how other people would approach this. Support for a "UninstallTask" seems to be a good solution for everyone who doesn't want to use a seperate installer product.

[jonwis]

Great questions! I'd normally say to use the Timer-triggered BG task.

Hey @andreww-msft and @aeloros - seems like a great "make background tasks easier" space. Do you have a good example of wiring up a bg task that drives the activation into a running app, like the other AppLifecycle work you've done?

[DrusTheAxe]

all in process background tasks need to be migrated to COM background tasks, which seriously implies C# too

What makes you say that?

C++ and Rust have options, to name a couple alternatives.

[DrusTheAxe]

when Windows is in sleep mode the periodic task keeps on being fired but the launch of the app seems to get queued. The side effect of this: when Windows goes out of sleep mode suddenly the app is launched 10 to 20 times.

Thats interesting. What version of Windows have you seen this? What kind of activation - UWP app, desktop bridge (aka Centennial), or...? What API are you using to activate the app - ActivateApplication(), Windows.System.Launcher, ShellExecute, CreateProcess on an AppExecutionAlias, other?

Interesting that activation and triggers don't have the same behavior re sleep. Sounds like activation (overtly, or coincidentally something in the call stack) is blocked during sleep.

@brialmsft @jsidewhite @kanismohammed @jonwis do you know more? Is this intentional? A bug?

[JosHuybrighs]

@DrusTheAxe

What version of Windows have you seen this? What kind of activation - UWP app, desktop bridge (aka Centennial), or...? What API are you using to activate the app - ActivateApplication(), Windows.System.Launcher, ShellExecute, CreateProcess on an AppExecutionAlias, other?

I see it on Windows 11, 22621.2861.
The background task is defined in the package manifest as:

<Applications>
  <Application ..>
    <Extensions>
        <Extension Category="windows.backgroundTasks" EntryPoint="SyncFolder.BackgroundTasks.ScheduleBackupTask">
          <BackgroundTasks>
            <Task Type="timer"/>
          </BackgroundTasks>
        </Extension>
   ...
</Applications>
<Extensions>
  <Extension Category="windows.activatableClass.inProcessServer">
    <InProcessServer>
      <Path>SyncFolder\WinRT.Host.dll</Path>
      <ActivatableClass ActivatableClassId="SyncFolder.BackgroundTasks.ScheduleBackupTask" ThreadingModel="both"/>
    </InProcessServer>
  </Extension>
</Extensions>

The code of the 'schedular' task is:

        public void Run(IBackgroundTaskInstance taskInstance)
        {
            var deferral = taskInstance.GetDeferral();
            string message = "Run";
            try
            {
                LaunchSyncFolder("ScheduleRequest", out message);
            }
            catch (Exception ex)
            {
			    message = ex.Message;
            }
            // Log message
            // ConditionalFileLogger($"SchedularTask - Result: {message}");
            // Removed because ConditionalFileLogger writes to a file in AppData\...\LocalData which doesn't
            // work because getting the folder using Windows.Storage.ApplicationData.Current.LocalFolder gives an exception.
            deferral.Complete();
        }

        void LaunchSyncFolder(string parmId, out string message)
        {
            message = "InitLaunch";
            try
            {
                if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
                {
                    FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync(parmId).GetAwaiter().GetResult();
                    message = "Launched";
                }
                else
                {
                    message = "NotFullTrust";
                }
            }
            catch (Exception e)
            {
                message = $"Exception in Launch: {e.Message}";
            }
        }

I now see that in order to avoid async in the definition of the Run method I call FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync with GetAwaiter().GetResult() added to it. I asume that this shouldn't make any difference (unless 'async' in case of a IBackgroundTask has some special meaning). Haven't tested this yet, but I will try to find out.

[DarranRowe]

@DrusTheAxe

all in process background tasks need to be migrated to COM background tasks, which seriously implies C# too

What makes you say that?

C++ and Rust have options, to name a couple alternatives.

The documentation.

[JosHuybrighs]

@DarranRowe @DrusTheAxe

One question that I have been meaning to ask. Since Mapping UWP features to the Windows App SDK has some interesting implications. First, C++ has no such thing as in process background tasks. Secondly, all in process background tasks need to be migrated to COM background tasks, which seriously implies C# too. Have you actually tried using this method for your background tasks?

I looked again at the documentation about porting UWP background tasks to a WinUI/WinAppSDK desktop app and tried the 2 methods proposed there for the 2 type of tasks I have:

• a task that runs every 15 minutes (TimeTrigger - <Task Type="timer"/>)
• a task that watches USB device inserts/removals (DeviceWatcherTrigger - <Task Type="deviceUse"/>)

Method 1: COM background tasks

This requires a COMServer for each task and some provisioning in your app to register at DCOM in order to act as the hosting process for the background task and allow your app to take that role both when opened by the user and not opened. A couple of remarks about this:

• With WinAppSDK 1.4 and VS17.8.3 RegistrationServices.RegisterTypeForComClients() is not available in .NET 6,7.. and so you need to do the registration with a p/invoke call to CoRegisterClassObject(). You do this each time the app is started.
• To allow your app to be the COMServer when not open you must add for each BG task a <com:Server..> definition in the manifest file with an argument that can be checked in the OnLaunched method to see if the app is opened by the user or not.
• I got only a TimeTrigger BG task working. Registration of the DeviceWatcherTrigger task causes the following exception:

Exception: System.Runtime.InteropServices.COMException
HResult: 0x80070032
InnerException: null
Message: ""
StackTrace:
at WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|39_0(Int32 hr)
   at ABI.Windows.ApplicationModel.Background.IBackgroundTaskBuilderMethods.Register(IObjectReference _obj)
   at Windows.ApplicationModel.Background.BackgroundTaskBuilder.Register()
   at SyncFolder.Services.AppBackgroundTasks.<RegisterTasksAsync>d__4.MoveNext() in C:\Users\joshu\Projecten\Eigen\trunk\SyncFolder\SyncFolder\Services\AppBackgroundTasks.cs:line 142

Pro: The task has full access to any shared code. It runs with MediumIL I think; only checked this with a Debug build with and without VS.

Method 2: C# OOP background tasks

This is the method I have been using from the start. Things to be aware of:

• Unfortunately this method requires that the BG task is defined in a seperate library and is a C#/WinRT component.
• Both tasks (TimeTrigger and DeviceWatcherTrigger) work without problems.
• The challenging part is: no BG task can run without having some kind of access to data that is provisioned and managed by the main app, be it a repository file or appsettings. How do you access this data?
  Being a C#/WinRT component one more or less has to recode all these classes inside the BG task project since referencing a shared library doesn't work.
  That comes with its own problems: because of WinRT 'imported' classes must all become 'internal' and 'async Task<>' type of methods must be reworked.

Conclusion

Method 1 has the advantage of running inside the app (it is InProc but not like in UWP) with full access to everything. Unfortunately it doesn't seem to support all type of BG triggers.
For the time being I will therefore stick to method 2.

None of the 2 methods are however straightforward and require considerable effort to make it work. A good document that describes this would be highly appreciated.