Does Windows 11 support exact-version activation for full-trust desktop MSIX?

No supported Windows 11 API documented here binds activation of a packaged full-trust desktop application to both an exact PackageFullName and manifest Application ID through first-image mapping.

1. Exact-version activation

The supported activation APIs take an AUMID, not a package full name:

• IApplicationActivationManager::ActivateApplication accepts appUserModelId, arguments, and activation options. It returns the process ID that fulfills the launch contract, but exposes no package-version or PackageFullName parameter.^1^
• AppListEntry.LaunchAsync launches the application as though the user selected its app-list entry. It likewise has no exact-package parameter.^2^

For packaged applications, the AUMID is derived from package family name + Package Relative Application ID. Package identity and application identity are distinct.^3^ Crucially, Microsoft documents the AUMID as independent of package version and architecture.^4^

Consequently:

• FindPackageForUser("", A) can retrieve the package identified by exact full name A.^5^
• GetAppListEntriesAsync can provide A’s application entries.
• Calling LaunchAsync on such an entry does not have a documented contract that carries A’s full name into activation or pins resolution to A.
• Passing the resulting AUMID to ActivateApplication cannot express A’s version because the identifier is version-independent.

None of these APIs documents a guarantee that A’s declared executable will be the first private image mapped.

2. Lifetime and dependency mechanisms

A package strong reference prevents the referenced package from being destaged. Registration, provisioning, static/dynamic dependencies, and a process using package content are examples of strong references.^6^ That is a payload-lifetime guarantee, not a documented lock on the current user’s registration or on AUMID-to-version activation selection.

Dynamic dependencies do not supply the requested transaction either:

• The dependency is created from criteria including package family, minimum version, and architecture; it cannot identify a specific MSIX package.
• If multiple packages satisfy the criteria, the highest version is selected.
• A runtime reference keeps the resolved package in active use until the last reference is removed or the referencing process exits.^7^
• AddPackageDependency adds the resolved package to the calling process’s package graph. Its documented guarantees concern using content and activating types from that dependency, plus side-by-side servicing; they do not bind a separate AUMID activation to the returned PackageFullName.^8^

Windows 11’s native dynamic-dependency implementation can target a main package only when that target opts in with uap15:DependencyTarget. Even then, its documented role remains package-graph/content dependency management—not exact-version launch of an application declared by that main package.^7^

Holding a Package, AppListEntry, COM, or WinRT object alive is also not documented as holding a registration lock. Object lifetime must not be treated as package-registration lifetime without an explicit API contract.

3. Replacement race: A versus B

If verification identifies full name A, registration changes, and B replaces A before version-independent AUMID activation:

• A is not guaranteed, because activation does not receive A’s full name.
• B is not guaranteed by the cited activation contracts.
• Failure is not guaranteed either.
• No cited public contract specifies which of A, B, or failure must result, or defines an atomic interval spanning verification, activation selection, and first-image mapping.

Therefore, for security design purposes, the outcome across that interval must be treated as unspecified by the supported public API contract. A post-launch identity/image check can detect an unacceptable result, but it does not make the initial mapping atomic.

If the requirement is that only previously authorized bytes from exact package A may begin executing, the available documentation does not establish a supported packaged-app activation primitive that satisfies it. An authoritative stronger guarantee would require a written determination from the Windows/MSIX activation team or a newly documented API contract; it cannot be inferred from package enumeration, staged-file retention, or dynamic dependencies.

References

1. IApplicationActivationManager::ActivateApplication method (shobjidl_core.h)
2. AppListEntry.LaunchAsync Method-Definition
3. An overview of Package Identity in Windows apps
4. AppListEntry.AppUserModelId Property-Definition
5. PackageManager.FindPackageForUser(String, String) Method-Definition
6. Package registration and lifetime
7. Use the dynamic dependency API to reference MSIX packages at run time
8. AddPackageDependency function (appmodel.h)