If you work with desktop applications on Windows and are still deploying everything with classic EXE or MSI installers, it's time to take a look at MSIX as a modern packaging formatIt not only improves installation and uninstallation, but also simplifies updates, mass deployment, and integration with the current Windows ecosystem, both locally and in the cloud.
Throughout this guide you will see, step by step, How to create MSIX packages in Windows From various perspectives: using the MSIX Packaging Tool, with Visual Studio, with advanced packaging designs using MakeAppx.exe, and also how all of this fits into scenarios like MSIX app attach in virtual environments. The goal is for you to end up with a practical and comprehensive understanding of how to package, sign, validate, and distribute your applications.
What is MSIX and why is it worth using?
MSIX is the modern installation and packaging format for Windows applications Microsoft designed it as a natural evolution of EXE, MSI, and AppX. It combines the advantages of traditional installers with the container philosophy of modern apps, resulting in more reliable, cleaner, and more predictable installations.
Unlike a classic EXE or MSI installer, an MSIX package is installs in a controlled containerwith clear rules about where it can write files and registry keys. This ensures that when the user uninstalls the application, everything belonging to it is removed, leaving no traces on the system that could clutter it over time.
MSIX inherits concepts from App-V and the UWP model, but without forcing you to go through the Microsoft Store or completely redo your projects. You can convert existing Win32, WPF, or Windows Forms applications (and in many cases without touching code) to an MSIX package that you can deploy with tools like Intune, Configuration Manager, PowerShell scripts or even double-clicks on the file.
Another key advantage is that MSIX is designed for optimize bandwidth and storageIt uses 64 KB blocks, avoids duplicating files between applications, and supports differential updates, so only the changes are downloaded—ideal if you distribute software from the cloud or to many machines on a network.
Furthermore, Microsoft offers an SDK that allows working with MSIX. on other operating systems such as iOS, macOS, Android, Linux, or older versions of WindowsThis opens the door to multi-platform distribution scenarios using the same packaging model.
Requirements and tools needed to create MSIX packages
To start creating MSIX packages properly, it's important to be clear about which tools you're going to use and in what environment. The minimum you'll need is Windows 10 version 1809 or higher, or Windows 11and administrator permissions on the machine where you perform the conversion.
The key utility for packaging existing desktop applications is the MSIX Packaging Toolwhich you can install from the Microsoft Store (recommended) or offline by downloading the package and provisioning it with PowerShell. It's also available via WinGet with a simple command like:
winget install “MSIX Packaging Tool” allow quickly install the MSIX packaging tool From the command line, provided you have the package client set up and a Store-compatible account when required.
In addition to the Packaging Tool, if you develop modern applications or maintain existing projects, you will find it very useful. Visual Studio 2019 or 2022 with the appropriate workloads (for example, “Desktop Development with C++” or “.NET for Desktop”) and MSIX-related extensions. Visual Studio includes wizards for generating packages and upload files for the Store.
In more advanced scenarios, the following comes into play MakeAppx.exeThe official command-line utility for compiling AppX/MSIX packages and their bundles from an XML packaging design. This tool allows you to automate the creation of complex packages with multiple components and resources.
Finally, if you work with Windows Virtual Desktop or Azure Virtual Desktop, or want to run applications in VHD or CIM containers, you'll be interested to know MSIX app attach and third-party tools such as MSIX Hero or the AppVentiX community, in addition to the MSIX Manager Tool to generate virtual disk containers with your packages.
Using MSIX Packaging Tool: Convert existing installers
The MSIX Packaging Tool is designed so that you can retrain existing installers (MSI, EXE, App-V 5.x, ClickOnce, and even manual or script-based installations) in an MSIX package without needing the original source code. It is especially useful for IT teams that want to modernize their software catalog without rewriting applications.
When you start the tool for the first time, you will be asked for consent to send telemetry data. Diagnostic data is limited to the behavior of the tool itself. and they are not used to identify or contact you. Once the telemetry submission is accepted (or not), you can choose between creating an application package, creating a modification package, or opening the package editor.
The most used option is create an application packageThis flow guides you from environment preparation to MSIX file creation, starting from an MSI, EXE, App-V, ClickOnce installer, an installation script, or even a manual process where you execute the steps you would take in a normal installation.
The Packaging Tool supports three conversion modes: packaging on the local machine, on a remote machine, or on a local Hyper-V virtual machine. If you already work in a clean environment (Without too many programs and services that might generate noise), the usual practice is to select the option to create the package on that same machine. If you prefer to isolate the process or have a test environment already set up, you can connect to a VM or a dedicated remote machine.
In the case of local virtual machines, keep in mind that Only Hyper-V VMs are supportedIf you use a different virtualization platform, you will need to use remote machine mode to connect to that machine and perform the capture from there.
Prepare the conversion machine
Before you begin capturing an installer, it's advisable to prepare the environment to minimize interferenceThe MSIX Packaging Tool includes a "Prepare computer" screen where you can leave the machine in an ideal state for the packaging process.
On one hand, the tool checks if the MSIX Packaging Tool driver The necessary software for capture is installed and enabled. Use DISM to check this, and if it detects that it is missing or disabled, it will attempt to enable it automatically. If you encounter errors here, it is recommended to review the troubleshooting documentation and, if the problem persists, report it through the Windows Feedback Hub.
Another important point is that the tool temporarily disable Windows Update during packaging to prevent changes unrelated to the application installation, such as system updates or updates from other apps, from being recorded.
The “Pending reboot” box is used as an indicator that there are system operations pending a reboot. The restart is not forced.However, it is recommended to do it manually if Windows reports that there are pending changes, and then restart the tool to work with a clean environment.
Additionally, you can optionally disable services such as Windows Search or the service of SMS Host From the same screen, by checking the corresponding boxes and using the "Disable selected" option. The tool itself will update the status to "Disabled" when it completes the operation, although these steps are not mandatory.
Once you have adjusted these parameters and verified that the environment is readySimply click on “Next” to proceed to the selection phase for the installer you want to convert.
Choose the installer to package and sign the package.
On the next screen you define which installer will capture the tool and how it will behave during the process. Here you can directly specify the MSI, EXE, App-V, ClickOnce file or the command line of a script, or leave the field blank and launch the installation manually when the tool begins monitoring.
If you choose a MSIThe Packaging Tool can read the package contents and automatically populate many of the MSIX manifest fields, saving considerable time later. If you're using MST transformations or MSP patches, you can specify them as arguments in the installer's parameter field.
In the case of installers App-V 5.1The process is even more straightforward. Simply select the App-V file, and the tool will translate the manifest to MSIX format, taking you almost immediately to the package creation screen. However, App-V 4.x versions are not supported in this workflow, and it is recommended to start with the original source installer.
To EXE and ClickOnceThe tool doesn't have a standard format for extracting metadata, so you'll have to manually fill in the package information (name, publisher, etc.) in later steps. Even so, they remain fully convertible as long as the installer behaves in a reasonably predictable way.
If what you have is a installation script Or if you prefer to perform the installation manually, you can specify the script command line or leave the field empty and run everything manually during the installation phase while the tool captures changes to the system.
This same screen allows you to configure the package signature preferencesMSIX requires that the package be signed in order to install it, so you can choose between Device Guard Signing (a Microsoft service based on Azure AD), your own .pfx certificate, a .cer file to validate that the publisher matches, or the option not to sign at this time (useful if you are going to sign at another stage of the pipeline).
If you choose a .pfx certificate, you will need to Navigate to the file and provide the password. If it's protected. With Device Guard Signing, you'll log in with an Active Directory account configured for this service and delegate the signing operation to Microsoft. It's also highly recommended to include a Timestamp URL (RFC 3161) so that the signature remains valid even if the certificate expires.
Fill in the MSIX package information
Once the installer and signing preferences are configured, the tool asks you to complete the package identity informationThese fields determine how the operating system sees your application, how it is updated, and how it will be displayed to the end user.
El Package name It is mandatory and corresponds to the package's internal identifier in the manifest. It is not displayed to the user, is case-sensitive, does not allow spaces, and must be between 3 and 50 alphanumeric characters, including hyphens and periods. Furthermore, It cannot end in a period or coincide with reserved names. such as CON, PRN, AUX, NUL, COM1-COM9 or LPT1-LPT9.
El Package display name Yes, it's visible to the user in the Start menu and on the Settings pages, so it should be descriptive and user-friendly. It can be between 1 and 256 characters long and supports translations if you work with multiple languages.
El Publisher's name It must conform to a distinctive name (DN) and, very importantly, It must match the subject of the certificate. with which you sign the package. It accepts a fairly long string (up to 8192 characters) and follows a specific regular expression with fields such as CN, O, OU, C, etc., in the style of X.509 certificates.
You can also define a Display Publisher NameThis is the human-readable text that the user will see in the application installer and system options. This field, like the package display name, supports up to 256 characters and can be translated.
La Package version It uses the quadruple notation "Major.Secondary.Build.Revision". Every time you release an update, you should increment this version, as Windows uses it to determine whether an installation is a new one or an update to an existing one.
La Description The package name is optional, but useful for internally documenting the purpose of the application or displaying explanatory text in the installation interface.
Field Installation location Define the path where the installer will copy the application payload, usually within "Program Files". This is optional, but recommended if the app is installed outside of that default folder. Make sure this path is correct. This matches what the installer does during the capture, so that the package correctly reflects the file structure.
Finally, you have the box for Add support for MSIX CoreThis allows your package to run on older versions of Windows that do not natively support MSIX, by selecting from a drop-down list the minimum Windows version you want to support with MSIX Core.
Application installation and capture phase
With the identity configuration complete, the Packaging Tool starts the monitored installation phaseFrom this point forward, everything you do to install and configure the application will be recorded and become part of the MSIX package.
The tool launches the installer in your chosen environment (local machine, VM, or remote), and you should follow its steps as you normally would, choosing the language, components, installation path, etc. It is important that The installation path matches the one declared before in the package information to avoid inconsistencies.
If the application needs to create shortcuts, especially one on the desktop or in the Start menu, it's best to do so during this phase so that The tool can capture the correct entry pointsSimilarly, if the software has prerequisites (frameworks, runtimes, .NET 3.5 or 2.0, additional components), you should install them now.
The tool allows you to run multiple installers or scripts While the capture is active, you can take advantage of this to package several pieces that are part of the same solution at once.
If the installation process requires a system restart, you can use the tool's own "restart" button or restart manually. Upon logging back in, the Packaging Tool will resume the process and continue the conversion flow right where you left off.
When you think that the installation and initial configuration Once the application is finished, click "Next" to proceed to first-start task management.
First boot management and services within the package
On the screen first launchThe tool lists the executables detected during installation. It is recommended to open the main application at least once to capture initial configuration tasks, profile creation, user folder generation, etc.
Select the executable file and click "Run" to launch it. If there are multiple executable files, you can mark which one is the one you want to run. main entry point. You can too remove unnecessary entries that you do not want to expose to the user as separate applications, using the "Remove" option.
If for some reason the main executable does not appear in the list, you can navigate manually to your locationRun it and then update the list to register it. This flexibility allows you to adapt the package to applications with complex binary trees.
When you move to the next screen, the tool will ask you Confirm if you have completed the installation and first-boot setupIf you choose “Yes, move on”, the flow continues; if you answer “No, I'm not done”, you will return to the previous screen to launch more apps, copy files, or adjust whatever is needed.
Starting with version 1.2019.1220.0, the Packaging Tool incorporates a services reportIf during the conversion it has detected services registered by the installer, it will display them grouped in two tables: “Included” (ready to package) and “Excluded” (those that require additional information or are not supported).
By double-clicking on a service you will be able to view and, in some fields, edit data such as display name, description, startup account, startup type (Automatic, Manual, or Disabled), arguments, and dependencies. The key name and image path, however, are not editable because they are part of the essential service definition.
Once you have reviewed this information, you can decide whether move a fixed service to the included list Or you can leave it out if you don't want to bundle it. This is very useful for controlling which services actually accompany the final application and avoiding surprises in production.
Creation and editing of the final package
In the final stage of the Packaging Tool you choose the location to save the generated MSIX fileBy default, the tool's local application data folder is used, but you can select any other path that is more convenient for your workflow.
If you also want to generate a conversion template fileThis is very useful for repeating future conversions of the same application with minor changes; you can specify a different save path for that file. Note that to generate this template, you must have specified an installer at the beginning of the process.
Before pressing the "Create" button, you can enter the package editor to review and modify the content or properties of the captured MSIX. From there, it is possible to adjust the manifest, paths, included files, application entries, visual resources, and other advanced details.
Upon completion of the creation, a pop-up window will appear indicating the exact path of the generated packetwith a direct link to open the folder, as well as the location of the tool's logs in the LocalState directory. From there you can close the tool, test the installation, or continue refining the package with the editor.
Creating MSIX packages from Visual Studio
When you develop modern applications or migrate projects to Windows App SDK and WinUI 3, Visual Studio makes the packaging process much easier. The key file is Package.appxmanifest, an XML that defines identity, capabilities, associations, icons and how the app integrates with the system.
From the Visual Studio manifest designer, you can configure everything without manually editing the XML: icons, screen orientations, system capabilities (camera, network, location, etc.), file associations, custom protocols, and more. Each tab in the designer groups related options and links to documentation if you need details.
In the tab Visual resources You define the logos and images that will be used in the Start menu, taskbar, app list, and toast notifications. It's important to provide the sizes that Windows requires (44, 150, 310, and other variations) so that the application looks sharp at any scale.
In the tab Packaging You enter the publishing details and choose which certificate will be used to sign the MSIX. Every packaged app must be signed, and for the user to install it without warnings, the certificate must be trusted by their computer (installed in the appropriate store or issued by a recognized CA).
If you think Distribute the application through the Microsoft StoreYou can associate the project with a Store app directly from Visual Studio using the Publish > Associate App with Store menu. This automatically synchronizes packaging fields with the data registered in the Partner Center.
To create the package, right-click on the packaged project (for example, a “Blank App, Packaged (WinUI 3 in Desktop)”) and choose Publish > Create App Packages. The wizard will guide you through selecting whether to package for sideloading or the Store, the signing method, and the target architectures (x86, x64, ARM).
Application package types and upload files
In the MSIX ecosystem, there are several types of files related to packaging, each with its own role. The most basic is the application package (.msix or .appx)This package contains the app and its resources for a specific architecture, such as x64 or x86. If you need to support multiple architectures, you will have to generate a package for each one.
To simplify cross-platform distribution, there are the bundled application packages (.msixbundle or .appxbundle)A bundle can contain several application packages, each for a different architecture (x86, x64, ARM). The system automatically chooses the one that corresponds to the device where it is installed.
When you want to submit the app to the Microsoft Store, a application package upload file (.msixupload or .appxupload)This file groups one or more bundles or individual packages together with the symbol file (.appxsym) used to analyze crashes and performance from the Partner Center.
Visual Studio can generate These files upload automatically If you choose the Store package creation options in the wizard, you'll only need to upload the .msixupload or .appxupload file to the Partner Center during the submission process.
Advanced packaging designs with MakeAppx.exe
As your applications grow in size and complexity, they often become divided into various packages: main, resources, optional content, DLC, etc.Managing all of this manually can be a nightmare, especially if you're not using Visual Studio. For these situations, there's the concept of a package layout (PackagingLayout) supported by MakeAppx.exe.
A packaging design is a XML document that describes the complete structure of a packaged application: package families, bundles, main packages, asset packages, files contained within each, inclusion/exclusion filters, etc. With a single XML file and one call to MakeAppx you can compile all the necessary packages.
In a simple example you would have an element PackagingLayout and a PackageFamily which acts as an application grouping. Here you define attributes such as ManifestPath (path to the base AppxManifest), FlatBundle (if you want a flat or classic bundle), ResourceManager (if you use MRT for resources) and even a unique identifier for that family.
Within PackageFamily you can define a Package for the main code (specifying ProcessorArchitecture: x64, x86, arm or neutral) and one or more AssetPackage For additional content (e.g., multimedia resources), you can specify AllowExecution=false so that the content does not require such thorough virus analysis because it does not contain executables.
Through the element Files and its File nodes define which files are included in each package: SourcePath marks where the files are located on your system or network, DestinationPath where they are placed within the package, and ExcludePath allows you to exclude files already selected by other patterns. single (*) and double (**) wildcards They let you recursively select sets of files and even rename them on the fly.
They also appear in advanced designs ResourcePackage For localized packages, you use the Resources and Resource nodes to assign language qualifiers, scale, etc., and mark one as the default. You can also define PackageFamily marked as Optional, which represent DLC or add-ons that can be installed separately, and the RelatedSet attribute controls whether they are updated in tandem with the main package.
If you already have pre-compiled packages that should be part of a grouping, you can reference them with Prebuilt Package, simply indicating the path to the existing .msix, .appx or .appxbundle so that MakeAppx takes it into account when building the global bundle.
To compile using a design, you run commands like MakeAppx.exe build /f PackagingLayout.xml /op OutputPackages\This generates all the packages described in the XML. Optionally, you can limit yourself to certain components with /id, point to a previous version with /ip to reuse packages that don't change, and automatically increment versions with /iv.
MSIX app attach and VHD/CIM containers
In virtual desktop environments, such as Azure Virtual Desktop, the use of MSIX app attach, a technique for mounting applications contained in MSIX packages within VHD, VHDX or CIM containers, avoiding inflating the base system image with dozens of programs.
The idea is to maintain a system image as clean and small as possibleand store applications on virtual disks that are mounted and associated with user sessions as needed. This way you can "attach" or "unattach" applications without reinstalling anything on the main image.
For this to work, it is essential that the MSIX packages are signed with a certificate of trustissued by an internal or public CA that the systems recognize. Without that trust, Windows will not allow the mounted packages to run.
Creating a VHD container from an MSIX file can be done in several ways. Microsoft offers the MSIX Manager ToolThis allows you to extract the package contents and package them into a virtual disk, ready to be mounted. Third-party utilities like MSIX Hero or tools from the AppVentiX community also automate this process and reduce the reliance on Hyper-V modules in PowerShell.
Once the VHD or CIM has been created, the virtual desktop environment is configured so that, upon logging in, Mount the disk and register the attached appso the user sees it as installed without taking up space in the base image. This approach simplifies version management, dynamic application allocation, and reduces maintenance time.
Installation, validation and distribution of MSIX packages
An MSIX package can Install with a simple double-click about the .msix or .msixbundle file. This opens the Windows application installer, which displays basic package information, the publisher, and an install button with a progress bar and error messages if something goes wrong.
When you generate packages from Visual Studio, PowerShell scripts are also created, such as Add-AppDevPackage.ps1, located in folders of the type *_Test. Running this script with “Run with PowerShell” allows you to install the package in an assisted manner, which is very useful in testing or continuous integration environments.
Before uploading anything to the Microsoft Store, it's advisable to run the package through the Windows Application Certification Kit (WACK)From the Visual Studio package creation wizard, you can launch WACK on the local machine or even on a remote Windows 10 device, provided you have the remote tools and the kit itself installed on that computer.
The WACK performs a test battery (performance, APIs used, background behavior, etc.) and generates a report. If the app passes certification, the package is ready to be submitted to the Partner Center. The .appxupload or .msixupload file is typically located in the AppPackages folder of the solution, and its name includes the version and supported architectures.
It is also possible Automate submissions to the Store from Visual Studio 2019 onwardsBy selecting the option to automatically send to the Microsoft Store after WACK validation, you must associate Azure Active Directory with your Partner Center account, create or link an Azure AD application with the administrator role, and retrieve credentials such as your tenant ID, customer ID, and customer key.
By configuring this data in the shipping options dialog box, Visual Studio can initiate the publishing process After completing the tests, you can track the status of the shipment from the "Check and Publish" window, reducing manual steps in your deployment pipeline.
With this entire ecosystem of tools, workflows, and formats, MSIX becomes the central piece for packaging, updating, and distributing Windows applicationsWhether you convert legacy installers with MSIX Packaging Tool, rely on Visual Studio for new developments, orchestrate complex packages with MakeAppx.exe, or deploy them in virtual environments using app attach, we offer cleaner, more controlled installations ready for the hybrid world of local desktop and cloud.
