Per-flavor execution contract for the four predefined script tasks.
Reference → Modules → Scripts → Tasks → Client Lifecycle Matrix
Lifecycle Matrix
FrameworX has four predefined script tasks that fire on platform lifecycle events. Each task has a fixed execution surface depending on which client flavor is connecting:
Predefined Task | WPF rich client | HTML5 / web client | Notes |
|---|---|---|---|
ServerStartup | n/a | n/a | Runs on the server (TServer.exe) at solution start, before any client connects. |
ServerShutdown | n/a | n/a | Runs on the server at solution stop. Reliable — server shutdown is graceful. |
ClientStartup | Yes | Yes | Runs once per client at session connect, on the client process. New in 10.1.5: the HTML5 / WebAssembly client now executes this task too. WPF behavior unchanged. |
ClientShutdown | Yes | No (by design) | Runs at client close. Browser tab close gives the HTML5 client no reliable shutdown window — tab kill, browser kill, navigation away, OS eviction on mobile, and device sleep all skip the unload phase. Wiring an unreliable hook would lie to script authors about determinism, so the platform deliberately does not invoke ClientShutdown on the web client. |
Designing for Web Compatibility
If you need teardown logic to fire reliably on web
Use the ServerShutdown task or a Server-domain script class instead. The server detects client disconnects and can perform any must-finish work centrally — saving state, releasing resources, persisting a session record.
If a ClientShutdown task body is non-empty in a web-targeted solution
The Designer's Build & Publish dialog emits a one-line info note in the build log (10.1.5 and later) so authors who copy a WPF solution to web don't silently lose teardown logic. Read it before you ship the web build.
API surface for ClientStartup on web
Client-domain task code is compiled twice — once for the rich-client target (.NET Framework 4.8) and once for the web target (WebAssembly-safe surface). WPF-only APIs (System.Windows.MessageBox.Show, System.Diagnostics.Process.Start, file-system access, registry, etc.) fail at publish time, not at runtime. A clean web publish is the contract that the script will run.
Background
The decision to make ClientShutdown rich-client-only on the web reflects a deliberate platform stance: contracts that can fire unreliably are worse than contracts that don't fire at all. A "best-effort" ClientShutdown would silently skip in the most common shutdown paths a real user creates (closing the browser, switching tabs aggressively, OS evicting a backgrounded tab on mobile), and any code written under the assumption that it runs would be subtly incorrect.
By contrast, the WPF rich client closes through a graceful MainWindow.Closing path that the platform can hook synchronously, so ClientShutdown fires deterministically there.