The topics in this section introduce options and guidance around deploying different types of Windows apps.
Advantages and disadvantages of MSIX-packaging
Your first decision will be whether or not to MSIX-package your app.
- MSIX-packaging. This is the process of packaging an app using MSIX technology (see What is MSIX?). MSIX-packaging gives your app a package identity (see the table below for why that's a benefit).
- Sparse-packaging. A way to opt out of MSIX-packaging (so that your app less restricted) while retaining package identity. For instructions on how to sparse-package your app, see Tutorial: Use the bootstrapper API in a non-MSIX-packaged app that uses the Windows App SDK.
- No packaging. Another way to opt out of MSIX-packaging (for the reason given above), but without package identity.
We recommend that you do MSIX-package your app. It'll be a modern and reliable packaging and deployment experience for your customers. Other ways of deploying your app involve other installation technologies, such as
|MSIX-packaging||Sparse-packaging or no packaging|
|Advantages||MSIX-packaging 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. MSIX also supports incremental and automatic updates. And the Microsoft Store optimizes for MSIX packages (MSIX can be used in or out of the Store).
MSIX-packaging also gives your app a package identity, which is needed for certain Windows features (for example, custom context menu extensions).
|If you choose not to go with MSIX-packaging, then 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.
Sparse-packaging means that it's still possible to get the same benefits from having package identity that MSIX-packaging gives you.
Your app will typically be installed and updated using
|Disadvantages||Your app is limited in terms of the kind of app it can be, and the agency it can have within the system. An NT Service isn't possible, for example. Inter-process communication (IPC) options are limited; privileged/elevated access is restricted if you're publishing to the Microsoft Store; file/Registry access are virtualized (but also see Flexible virtualization). And in some situations enterprise policies can disable MSIX updates by disabling the Microsoft Store.||An app that doesn't use MSIX 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.|
Use the Windows App SDK
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.
- Create an MSIX package from an existing installer
- Build an MSIX package from source code
- Manage your MSIX deployment
You can also package and deploy these types of apps using 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
UWP apps are packaged and deployed using MSIX.
Submit and view feedback for