Is WindowsAppSDK ready/suitable for desktop apps that need some form of background tasks

[JosHuybrighs]

I am slowly starting to wonder whether this WindowsAppSDK is ever getting to the point where it is THE framework to use when you want to do something that is more complex than simply showing a UI and then execute some code from within the app/package.
In particular the lack of serious support for Background tasks make it impossible to build a package that requires for instance a periodic background task.
The issue has been raised almost 2 years ago. Simply search for OOP in the Discussions section on Github.

• Visual Studio still doesn't come with a template to create the WinRT library project that is needed for this. One needs to create a library and then add the necessary hooks in there. For me that means it is seen as something not being important.
• The latest version of Visual Studio doesn't built anymore when the background project uses a library project that is being shared by other projects in the solution (see here). Really? Do I have to re-code the shared code in the background project?
• InProc background tasks would solve the above, but no sign of it.
• The possibility to not use a timer background task but instead register a task on the Windows Task Schedular doesn't work either because WindowsAppSDK is missing a Uninstall trigger that will be needed to de-register the task when the package is being uninstalled.

Is someone using this framework? Is Microsoft using it? Are desktop apps dead (see the new Outlook for Windows)?

Any feedback to make me feel more assure of what I am doing?

[DarranRowe]

The answer to that is that the Windows App SDK will probably never be a "framework".
The goal of the Windows App SDK seems to be more about filling in gaps in the existing API, or providing new functionality not already available. This is outlined in the FAQ. Of course, the information in these links is a little outdated, but the concept still hasn't seemed to have changed.
This means that you will still be writing a desktop application that happens to use the Windows App SDK as a library, but this will be a library on top of whatever foundation you are using. You can see this here because the whole packaging thing is the Windows packaging system. If you want evidence of this, set Visual Studio to diagnostic logging and look at how it creates the packages. It uses makeappx.exe from the Windows SDK. In particular, it uses the Windows SDK Build Tools NuGet package to supply makeappx.exe. But it is the same makeappx.exe that was used to make UWP packages.
Background tasks are WinRT components that implement the Windows.ApplicationModel.Background.IBackgroundTask interface. You don't even need to reference the Windows App SDK when you are writing the out of process component. Or even starting up the background task if you are using something like a Windows API application or a .NET WinForms or WPF application type.

In general, this issue is completely independent of the Windows App SDK. If you completely remove WinUI 3 from the equation, you can do exactly what you stated in your post using a Windows API application or a Windows Forms application or even a WPF application.

[JosHuybrighs]

@DarranRowe
Ok, this discussion could probably then better have been posted on GitHub WinUI, but I still think that Background tasks have to be part of the Windows App SDK. To me background tasks are controlled/handled by the App Lifecyle Model, in particular when they are InProc. And the App Lifecycle api is in the WindowsAppSDK.

As is mentioned in What's supported when migrating from UWP to WinUI3 background tasks are supported in C# but only OOP (and only when not using a shared library as is stated here. Both Inproc and OOP is possible with C++.

What could one then conclude?

• Microsoft wants me to use 'older' methods (C++, WinForms, WPF, pure win32) when things are more advanced then a simple UI.
• Problems with background tasks on WinUI/WindowsAppSDK are almost 2 years old and no solution on the horizon.
• Alternative approaches using the Windows Task Schedular or a Windows Service are a no-go because they require some sort of de-registration that is not possible with a MSIX package. A Uninstall trigger will be needed as brought up in #2654.

If it wasn't for the much better UI one should wonder why people, developing in C#, would want to use this.

[DarranRowe]

@JosHuybrighs
The only comment that I have then is, have you really looked at the Windows App SDK App Lifecycle classes? If so, all I can ask is, how does an app instancing API or the extended activation classes, which pass through to the internal Windows activation functionality when an app is packaged, mean that the background tasks have to be part of the Windows App SDK?

[JosHuybrighs]

@DarranRowe
Ok, understood.
I will close the discussion because you are correct. This is indeed not about the WindowsAppSDK.

Hopefully, at some point in time Microsoft comes up with InProc Background tasks for C# when building a WinUI3 packaged desktop app and with the possibility to hookup a Uninstall task.