Packaging And Identity
Package identity is not just install metadata. It changes which Windows features your app can use.
Three Packaging Models
| Model | Identity | Best for |
|---|---|---|
| Packaged MSIX | Yes | New WinUI 3 apps, Store, enterprise MSIX, package-identity features |
| Packaged with external location | Yes | Existing installer apps that need identity-only features |
| Unpackaged | No by default | Internal utilities or custom deployment where MSIX is blocked |
Why Identity Matters
Package identity enables or simplifies features such as:
- App notifications.
- Startup tasks.
- File and protocol associations.
- Share targets.
- App services.
- Background tasks and other extension points where supported.
- Store and enterprise deployment workflows.
If the feature list includes identity-dependent behavior, default to packaged MSIX unless an existing installer constraint forces another path.
Settings And Storage
Packaged apps can use package-aware app data APIs. Unpackaged apps should plan their own settings/storage paths, usually under the user’s local application data folder.
Do not write code that assumes ApplicationData.Current.LocalSettings is valid in every deployment model.
Decision Checklist
Does the app need notifications, startup tasks, file associations, share targets, or Store MSIX?
If yes, choose a package identity path.
Does the app already have an installer that cannot move to MSIX?
If yes, evaluate packaging with external location.
Is this an internal tool with no identity-dependent features?
If yes, unpackaged may be acceptable, but runtime/signing/updates become your responsibility.