Edit

Share via

Packaging overview

Packaging defines how your app is installed, updated, and integrated with Windows. WinUI apps are packaged by default, while many desktop apps, such as traditional Win32 applications, run unpackaged. 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, and other extensibility points. Unpackaged apps can still access many Windows App SDK capabilities, but may require additional setup to enable certain features.

Why app packaging matters

Packaging determines how your app is installed, updated, identified, and integrated with Windows. 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. The goal of this overview is to help you quickly understand the trade-offs so you can choose the model that best matches your app’s architecture and requirements.

Packaged vs. unpackaged apps

Packaged apps

Packaged apps use MSIX and have package identity, which is required for many Windows extensibility points—including background tasks, notifications, custom context menu extensions, and share targets. Package identity allows Windows to reliably identify the caller of platform APIs, which is why these features depend on it. For more information, see Features that require package identity.

Packaged with external location

Some existing desktop apps aren't yet ready for all their content to live inside an MSIX package. Packaging with external location gives these apps package identity while allowing most of their content to remain outside the package.

Unpackaged apps

Unpackaged apps don't use MSIX and don't have package identity, which means they cannot access the features that require it..

  • 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.
  • See Features that require package identity.

Summary comparison

Packaged (optional app container) Packaged with external location / Unpackaged
Key benefits Modern install/uninstall, automatic/incremental updates, clean removal with no leftover artifacts, optimized Microsoft Store experience, and access to features requiring package identity. Full control over process model, elevation, IPC, registry and file system access. External-location packaging allows gaining package identity without fully adopting MSIX.
Key limitations Some system-level scenarios aren't supported (e.g., NT Services). IPC options can be limited, Store publication restricts elevated access, and virtualization applies in many cases (see Flexible virtualization). Enterprise policies may disable Store-driven updates. Higher risk of stale files or configuration after uninstall. Installation/update must be handled manually via .exe, .msi, or custom mechanisms. Unpackaged apps lack features that require package identity.

Important

For most apps, using MSIX and running in an app container provides the most seamless, secure, and modern installation and update experience.

For more details about install location, working directory, virtualization, and runtime behavior, see
Understanding how packaged desktop apps run on Windows.

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.

Other installation technologies

You can also package and deploy these types of apps using other installation technologies.

  • Last updated on