Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Packaging defines how your app is installed, updated, and integrated with Windows. WinUI 3 apps are packaged by default, while many desktop apps, such as traditional Win32 applications, run unpackaged. Choosing between a packaged or unpackaged app affects the features you can use, the deployment model you rely on, and the overall experience your customers get.
Note
Building a new WinUI 3 app? You're already packaged by default. The guidance below is most relevant for developers who need to make an explicit choice — typically when porting an existing app, deploying to enterprise machines, or adding Windows features to an app that wasn't originally packaged.
Why app packaging matters
Packaged apps benefit from a clean installation model, automatic updates, and access to Windows features that require package identity — including background tasks, notifications, context menu extensions, share targets, and other extensibility points. Packaging also helps ensure cleaner deployments, reliable updates, and streamlined distribution through channels such as the Microsoft Store and enterprise deployment tools.
Features that require package identity
These Windows features only work in apps that have package identity — either through full MSIX packaging or packaging with external location (Sparse packaging).
| Feature | Description |
|---|---|
| Background tasks | Run code when your app isn't in the foreground — for example, to sync data, process downloads, or respond to system events. |
| Windows AI APIs (Phi Silica, OCR, etc.) | Access on-device AI capabilities such as local language models, text recognition, and image analysis. |
| Push notifications (WNS) | Receive real-time notifications from your cloud service through the Windows Notification Service. |
| Share target | Let users share content from other apps directly into yours via the system Share sheet. |
| Custom context menu extensions | Add your app's actions to the right-click menu in File Explorer and other shell surfaces. |
| File type and protocol associations | Register your app as the handler for specific file types or URI protocols (e.g., yourapp://). |
| Startup tasks | Launch your app automatically when the user signs in to Windows. |
| App services | Expose background services that other apps can call into, enabling inter-app communication. |
Tip
If you're unpackaged and hitting E_ILLEGAL_METHOD_CALL or APPMODEL_ERROR_NO_PACKAGE errors when calling Windows APIs, that's the package identity requirement. See packaging with external location (Sparse packaging) as the lowest-friction fix.
For more information, see Features that require package identity.
Packaging models at a glance
| Model | Package identity | Installer | Store eligible | Best for |
|---|---|---|---|---|
| Packaged (MSIX) | ✅ Yes | MSIX replaces installer | ✅ Yes | New apps, Store publishing, enterprise MDM |
| Packaging with external location | ✅ Yes | Your existing installer | ❌ No | Existing apps with own installer, ISVs |
| Unpackaged | ❌ No | XCopy / script | ❌ No | Internal tools, dev utilities, simple scenarios |
Packaged apps (MSIX)
Packaged apps use MSIX and have package identity, which is required for many Windows extensibility points. Package identity allows Windows to reliably identify the caller of platform APIs, which is why these features depend on it.
- Packaged apps typically run in a lightweight app container with file system and registry virtualization (see AppContainer for legacy apps and MSIX AppContainer apps).
- Apps can also be configured not to run in an app container if needed.
- MSIX is used both for packaging and installation (see What is MSIX?).
Packaging with external location (Sparse packaging)
Packaging with external location (also called sparse packages) lets you register a small identity package alongside your existing app — without changing your installer, binary locations, or update process. It was introduced in Windows 10 version 2004 (build 19041).
This is the sweet spot for existing Win32/WPF/WinForms apps that ship via their own installer (NSIS, WiX, InstallShield, etc.) and don't want to replace it with MSIX. You register a lightweight identity package, your binaries stay where they are, and you unlock the full set of package-identity-gated Windows features.
| Capability | MSIX | External location |
|---|---|---|
| Replaces your installer | Yes | No |
| Binaries inside the package | Yes | No (external) |
| Store eligible | Yes | No |
| Package identity | Yes | Yes |
| Update mechanism | MSIX update | Your existing mechanism |
→ Full walkthrough: Grant package identity by packaging with external location
Unpackaged apps
Unpackaged apps don't use MSIX and don't have package identity, which means they cannot access the features listed above.
- They remain fully unrestricted in terms of API surface, file system access, registry access, elevation, and process model.
- Installation and updates rely on
.exe,.msi, custom installers, ClickOnce, or xcopy deployment.
Before you commit to unpackaged, check the features table above against your roadmap. If notifications, background tasks, or AI APIs are on the horizon, consider starting packaged.
Choose by scenario
| Scenario | Recommended model | Details |
|---|---|---|
| Indie developer publishing to the Microsoft Store | Packaged (MSIX) | The Store requires MSIX. WinUI 3 apps are packaged by default — no changes needed. → Distribute your packaged app |
| Enterprise app deployed via Intune or Configuration Manager | Packaged, or external location for existing installers | New apps should use MSIX. Existing apps with their own installer can use packaging with external location. → Deploy packaged apps |
| ISV shipping a direct download with own installer | Packaging with external location | Register a lightweight identity package alongside your existing installer. Users see no change; you get Windows features. → Grant package identity |
| Internal tool or developer utility | Unpackaged | Simplest to build and deploy. The Windows App SDK works via NuGet, but some features won't be available. |
Framework-dependent vs self-contained deployment
Separately from packaging model, apps using the Windows App SDK choose how to carry their runtime dependencies:
- Framework-dependent: The Windows App SDK runtime must be installed on the user's machine. Smaller app footprint; relies on the runtime being present or auto-installed.
- Self-contained: All Windows App SDK binaries ship with your app. Larger footprint; no external runtime requirement. Good for locked-down enterprise environments.
Get started with MSIX
If you build a Win32 desktop app (sometimes called a classic desktop app) or a .NET app — including Windows Presentation Foundation (WPF) and Windows Forms (WinForms) — then you can package and deploy your app using MSIX.
- Create an MSIX package from an existing installer
- Build an MSIX package from source code
- Manage your MSIX deployment
Other installation technologies
- Application installation and servicing
- Windows Installer
- .NET application publishing overview
- Deploying the .NET Framework and applications
- Deploying a WPF application
- ClickOnce Deployment for Windows Forms
Related content
Collaborate with us on GitHub
The source for this content can be found on GitHub, where you can also create and review issues and pull requests. For more information, see our contributor guide.
Windows developer