Proposal: Support Application.ShutdownMode for WinUI 3

[heftymouse]

Proposal: Support Application.ShutdownMode for WinUI 3

Summary

Add the Application.ShutdownMode property from WPF to WinUI 3, for finer-grained control of app lifecycle.

Rationale

A large number of apps are 'daemon-like' and need to run in the background as a system tray icon or otherwise until invoked. However, WinUI 3 in its current state does not allow for this as it terminates the application when all its windows are closed. Adding Application.ShutdownMode would allow developers to configure this and run in the background without resorting to ugly workarounds.

Scope

Capability	Priority
This proposal will allow developers to control the automatic termination behaviour of WinUI	Must

Important Notes

None

Open Questions

This isn't a perfect solution since apps running without any sort of UI can offer poor UX since the user is unaware that it is still running. In the future, the framework itself may need to support background apps in a user-friendly way (perhaps with microsoft/WindowsAppSDK#713?)

[BreeceW]

The Windows App SDK 1.5-experimental2 release from a few days ago has added an experimental API, Application.DispatcherShutdownMode, with the options OnLastWindowClose and OnExplicitShutdown.

[fredemmott]

For anyone who really needs this now, it's doable by:

1. getting your hwnd via IWindowNative
2. subclassing or otherwise hooking the hwnd
3. intercepting WM_CLOSE and starting your shutdown; call this->Close() (or ShowWindow() on the hwnd)
4. intercepting WM_DESTROY and ignoring it - the WM_DESTROY message is what triggers the application exit on v1.4
5. When you actually want to exit, call PostQuitMessage() from the main thread
6. Leave a TODO/issue/task to remove this when you upgrade to v1.5 :)

My use case is is I have some background coroutines in various threads that must be shutdown cleanly, and I need to keep the dispatcher queues running until that has done; an immediate exit causes problems. The "the app's exiting, it doesn't matter if you just drop everything on the floor" approach doesn't apply when (a) they can connect to external systems (b) improper cleanup can still end up calling the destructors, but in the wrong thread, leading to crashes, Windows Error Reporting popups, etc.

[bpulliam]

This is included in 1.5. See the 1.5 release notes for more details.