Deployment overview

The topics in this section introduce options and guidance around deploying different types of Windows apps.

Advantages and disadvantages of packaging your app

Your first decision will be whether or not to package your app.

  • Packaged app. A packaged app is one that's been packaged using MSIX technology (see What is MSIX?). Importantly, a packaged app has package identity at runtime; package identity is needed for certain Windows features (for example, custom context menu extensions).
    • Very commonly, a packaged app's process runs inside a lightweight app container; and is isolated using file system and registry virtualization.
    • Packaged app with external location. But you can opt out of those restrictions and still be a packaged app (still benefit from package identity). You do that by building and registering a package with external location with your app. A packaged app with external location uses MSIX to package, but it's not installed by using MSIX (instead, it's a "bring-your-own-installer" model). It's essentially a hybrid option between a packaged and an unpackaged app. See Grant package identity to an unpackaged app.
  • Unpackaged app. Another way to opt out of the restrictions described above is to create an unpackaged app, and not use MSIX at all. But be aware that an unpackaged app doesn't have package identity at runtime; so it misses out on certain Windows features.

Each type of app can be published to the Microsoft Store, and installed that way or via Windows App Installer.


We recommend that you package your app to run in an app container. It'll be a seamless, modern, and reliable installation and update experience for your customers.

Packaged to run in an app container Packaged with external location or unpackaged
Advantages Gives your users an easy way to install, uninstall, and update your app. Uninstall is clean—when your app is uninstalled, the system is restored to the same state it was in before installation—no artifacts are left behind. This kind of app also supports incremental and automatic updates. And the Microsoft Store optimizes for apps of this kind (although they can be used in or out of the Store).

You get the benefits of having package identity.
With these options, your app is unrestricted in terms of the the kind of app it is, the APIs it can call, and its access to the Registry and file system.

Packaging with external location means that you get the benefits of having package identity.
Disadvantages Your app is limited in terms of the kind of app it can be, and the agency it can have within the system. For example, an NT Service isn't possible. Inter-process communication (IPC) options are limited; privileged/elevated access is restricted if you're publishing to the Microsoft Store; file/Registry access is virtualized (but also see Flexible virtualization). And in some situations enterprise policies can disable updates by disabling the Microsoft Store. With these options, an app that is at risk of causing stale configuration data and software to accumulate after the app has been uninstalled. That can be an issue for the customer and for the system.

Your app will typically be installed and updated using .exe or .msi files, or via other installation and update solutions; using a custom installer, ClickOnce, or xcopy deployment.

An unpackaged app lacks lacks the benefits of having package identity.

Use the Windows App SDK

After deciding whether or not to package your app, you can next decide whether or not to use the Windows App SDK in your app. See Windows App SDK deployment overview.

Win32 and .NET desktop apps

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.

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

UWP apps

UWP apps are packaged and deployed using MSIX.