Expose AppInstallManager APIs through compiled C# PowerShell cmdlets

Goal

Expose the documented Windows.ApplicationModel.Store.Preview.InstallControl.AppInstallManager surface through in-process, compiled C# PowerShell cmdlets with typed pipeline output, explicit user scope, native asynchronous/error handling, and safe confirmation.

This is a capability-gated backlog, not a promise that these APIs are available to ordinary PowerShell hosts. It is distinct from the existing .appinstaller/PackageManager helpers and should not replace their behavior.

Scoped development decision — 2026-09-14

The official AppInstallManager documentation states that access is protected by a private capability restricted to Microsoft-developed apps. The requirements table also lists runFullTrust; that must not be interpreted as sufficient authorization by itself. The maintainer approved scoped development based on observed activation, getter access and a caller-scoped paused-only update search. Do not bypass capability, identity, policy, licensing or authorization restrictions, and do not describe this evidence as a generally supported third-party distribution contract.

The maintainer has cleared the blanket access blocker for #234 and the initial caller-scoped work in #236, #238 and #244. Existing implementation dependencies still apply. #233 remains open for authoritative support clarification, but its closure is not required to start this approved subset.

All other API families, plus per-app/ForUser/automatic-update variants not demonstrated by the probe, remain gated. No live installs, entitlements, queue controls or settings changes are authorized by this development decision. Any broader scope requires its own validation and approval before it can merge or ship.

Evidence: host/getter matrix and authorized caller-scoped search. This is empirical runtime evidence, not an official third-party support guarantee.

Coverage

• Capability/host feasibility and a shared compiled WinRT/PowerShell foundation.
• Queue inventory, grouped items, current status and event-driven monitoring.
• Product installation, update search and package-family update requests.
• Cancel, pause, restart and download-queue priority.
• Applicability/installation-policy checks, free entitlements and manager settings.
• Account for every documented AppInstallManager property, event and non-retired method family; explicitly document unsupported or deferred members rather than silently omitting them. Related item/status/options types support those operations rather than expanding this epic into every Store API.

StartAppInstallAsync is documented as retired and must not become the new default implementation. Use supported StartProductInstallAsync / StartProductInstallForUserAsync overloads where the access gate permits them. Installation should occur after first sign-in, not during OOBE, per the documentation.

Shared acceptance criteria

• Compiled C# cmdlets execute WinRT in-process; no Windows PowerShell 5.1 shell-out, CLI text parsing, private protocol emulation, or unrelated module rewrite.
• PowerShell 7.4+ compatibility, Windows/version/capability gates and explicit access errors. Importing portable code must not activate the manager, install dependencies or mutate settings.
• Separate request acceptance from terminal installation/update success. Preserve identities, user scope, HRESULTs, cancellation and unknown outcomes in typed results.
• ShouldProcess protects every install/update/control/entitlement/settings mutation; -WhatIf performs none of those actions. Consent for forced restart, launch, pinning, notification changes or all-user scope is explicit.
• All cmdlets ship deterministic Pester 6.2+ coverage, comment-based help, public documentation and unreleased notes in their own implementation PR. Use fake adapters by default; no real installs, entitlement grants or policy changes in CI. Authorized opt-in integration evidence must be leak-safe.
• No credentials, private endpoints, capability bypasses or hardcoded account/telemetry identities. Expose only documented options and disclose their scope and side effects.
• Existing AppInstaller helpers and package-update orchestration remain unchanged unless a separate change is explicitly approved. No automatic installation or release is authorized by this backlog.

Delivery order

Start #234 now. After the foundation, initial caller-scoped queue inspection (#236) and settings reads (#238) may proceed; caller-scoped all-app searches with automatic download/install and forced restart disabled (#244) also require the inventory contract. Other features retain their access/validation prerequisites. Keep #233 open for support clarification and maintain an API-to-cmdlet matrix that distinguishes observed, unverified, retired and blocked members.

Actual GitHub sub-issues below are the implementation-sized units; their dependency sections define ordering.

Sources

• AppInstallManager — members, version history, private-capability restriction and OOBE guidance
• AppInstallItem
• AppInstallStatus
• AppInstallOptions
• AppUpdateOptions

Sub-issue plan

Bash parity: not applicable; this epic concerns Windows-only WinRT APIs.

Start with sub-issue #234 and the AppInstallManager documentation, then review the delivery-order dependencies and the API-to-cmdlet matrix described here. This epic is done only when its approved scoped sub-issues, typed results, capability gates, ShouldProcess protections, deterministic Pester coverage, help, documentation, and release notes meet the shared acceptance criteria.