Defer AppInstaller updates when the application is running

Problem

Update-AppInstallerApp should not fail merely because an AppInstaller-managed application is running. Prefer a supported, non-disruptive update/deferred-registration mode so the application can continue running and the update can take effect at the platform-defined safe point.

This should also benefit Update-AllPackages -Provider AppInstaller, which uses the canonical updater. Do not force-close applications, terminate processes or lose unsaved work as an implicit part of updating.

Current implementation

modules/Shmuelie.Windows/Cmdlets.AppInstaller/AppInstallerService.cs, Update, calls PackageManager.AddPackageByAppInstallerFileAsync with AddPackageByAppInstallerOptions.None, waits for the deployment result and propagates ExtendedErrorCode.

API compatibility to resolve

Microsoft documents AddPackageOptions.DeferRegistrationWhenPackagesAreInUse as delaying registration of in-use main/dependency packages until the application's next activation. However, the current AddPackageByAppInstallerFileAsync overload takes the different AddPackageByAppInstallerOptions enum, whose documented members do not include that deferral flag.

Confirm a supported AppInstaller-compatible API/options flow before implementing. Do not invent an enum member, cast an unrelated flag into the current enum, or silently replace the AppInstaller source with an incompatible package-URI operation. Preserve AppInstaller registration/source semantics, package identity and dependency handling.

Acceptance criteria

• Select supported update/deployment options that defer application of an in-use update instead of failing solely because the application is running. Document the actual deferral/completion point and any OS/API limitations.
• Keep the default behavior non-disruptive: no implicit force shutdown, process termination or restart. Do not retry with destructive options.
• Preserve ShouldProcess, -WhatIf, confirmation and exact pipeline identity binding. Preview must not stage, register or submit an update.
• Preserve the default void output and the opt-in -PassThru contract. Report only what the API establishes: a completed/accepted deferred request is not proof that the running app has been upgraded or its installed version changed.
• Keep aggregate AppInstaller results equally honest. Do not turn an in-use error into success merely by swallowing it; require evidence of supported deferral. Unrelated failures and unsupported deferral remain explicit.
• Add deterministic compiled-boundary/provider tests for running versus stopped apps, deferred acceptance, request failures, unsupported options/platform versions, preview and confirmation. Use fakes for development; any live validation should use an explicitly authorized controlled app.
• Update canonical help, module README and unreleased notes. Preserve ordinary successful updates when the application is not running.

References

• AddPackageOptions.DeferRegistrationWhenPackagesAreInUse
• AddPackageByAppInstallerOptions
• Add-AppxPackage deferred-registration example

This concerns the existing Windows.Management.Deployment AppInstaller updater, not the separate experimental AppInstallManager feature family or its release hold.

Start in modules/Shmuelie.Windows/Cmdlets.AppInstaller/AppInstallerService.cs, especially Update and its AddPackageByAppInstallerFileAsync call, then verify the referenced Windows deployment APIs and options for AppInstaller compatibility. Use fakes at the compiled boundary to cover running and stopped apps, deferral, failures, preview and confirmation; done includes updated canonical help, the module README and unreleased notes without changing output or identity-binding contracts.