How to create MSIX packages step by step and without surprises

If you work with application deployment on Windows, sooner or later you'll run into the MSIX formatThis format has become Microsoft's main bet for packaging software, and it's important to be clear about it. How to create MSIX packages correctly and repeatedly if you want to avoid headaches in production.

In the following lines you will find a very complete, step-by-step explanation about How to prepare the environment, convert classic installers to MSIX, sign, validate and distribute your packagesWhether you use MSIX Packaging Tool, work from Visual Studio, or online commandsThe idea is that you end up with a global and practical overview, but without losing sight of the important technical details.

What is MSIX and why is it worth using?

MSIX is the modern application packaging format for Windows It unifies and improves upon previous technologies such as MSI, AppX, and App-V. It's not just "another installer": it adds isolation, cleaner management, and advanced on-premises and cloud distribution options.

Among its key advantages are the reliability of installation and uninstallation (Microsoft speaks of success rates exceeding 99,9%), the ability to leave the system "clean" when the app is uninstalled, and the reduction in disk space thanks to Avoid duplicating common files across multiple applications.

MSIX is designed to work well in modern scenarios: optimizes bandwidth (64 KB blocks ready for distribution from the cloud), integrates with the Microsoft Store, with management tools such as Intune or Configuration Manager, and is compatible with technologies such as MSIX app attach for remote desktop environments and Windows 365.

The main tool for converting legacy installers (EXE, MSI, App-V, ClickOnce, scripts…) into MSIX packages is MSIX Packaging ToolAvailable in the Microsoft Store and also as an offline package. Additionally, Visual Studio allows Generate MSIX directly from source code in UWP projects or with Windows application packaging projects.

Routes to reach an MSIX package

Before you start converting anything, it's a good idea to decide how you're going to generate your packages. Depending on whether or not you have access to the source code, one approach will be more suitable than another. create MSIX packages that are easy to maintain.

If the application is under active development and you control the code, ideally you generate the MSIX in the compilation process itself: with Visual Studio (UWP or Windows application packaging projects) or through the MSIX command-line tools integrated into your build system (Azure DevOps, Jenkins, etc.).

On the other hand, if you have to deal with legacy installers already compiled (MSI, EXE, App-V 5.x, ClickOnce, custom scripts…) or even with applications for which you have no code, the recommended route is to use MSIX Packaging Tool on a conversion machine to capture the installation and generate the package.

In desktop virtualization and WVD/Azure Virtual Desktop scenarios, in addition to generating the MSIX, it is common to transform that package into a VHD/VHDX or CIM container to be able to use it with MSIX app attach, keeping the base images lightweight and "gluing" the apps according to the user.

Prerequisites and preparation of the conversion environment

For the conversion to go well, it is essential to start from a clean and controlled environmentIf the system is cluttered with software and background processes, the tool may pick up noise, resulting in an unreliable package.

The minimum requirements to use MSIX Packaging Tool are: Windows 10 version 1809 or laterA Microsoft account if you're installing it from the Store, membership in the Windows Insider program only if you're using Insider builds, and having Administrator privileges on the machine where you run the tool.

It's advisable to dedicate a machine (physical, local VM with Hyper-V, or remote) exclusively to the capture. The tool itself lets you choose whether you want Create the package on the current machine, on a remote machine, or on a Hyper-V VM. from your computer. This makes it easier to keep images clean and ready to convert.

During preparation, MSIX Packaging Tool checks and attempts to automatically activate the packaging controller which you need to monitor the installation. You can also temporarily pause Windows Update and, optionally, stop services such as Windows Search or the SMS host to prevent extra activity that contaminates the packet.

If there pending restarts The tool will tell you when to restart the system. It's not mandatory, but it's recommended to restart before continuing with the capture to avoid interrupted operations that could affect monitoring.

Install and update MSIX Packaging Tool

The most common way to get the tool is to download it from Microsoft Store With your Microsoft account, simply search for “MSIX Packaging Tool”, go to the product page, and start the installation. From then on, it will automatically update to the latest stable versions.

If you prefer to automate it or work from the console, you can install it with winget install “MSIX Packaging Tool”This greatly facilitates deployment in managed environments or laboratories.

There is also a variant offline Designed for machines without access to the Store, this includes the application package and its license. In that case, you add the package to the system with PowerShell (for example, by means of Add-AppxProvisionedPackage pointing to the MSIX path and the XML license).

The tool is frequently updated. Recent versions have significantly improved integration with the Package Support Framework (PSF), which is used to apply runtime corrections to applications that do not behave well in the new container model without touching their code.

Choosing an MSIX package type and understanding the variants

When working with MSIX, we're not just talking about "one package," but several types with different uses. Understanding these variations helps you to plan how to distribute and install your applications in each scenario.

The basic format is the application package (.msix or .appx)This contains the app and its resources for a specific architecture (x86, x64, ARM, ARM64, etc.). If you want to support multiple architectures, you'll need one for each processor type.

Above it is the application bundle (.msixbundle or .appxbundle)which packages several MSIX packages for different architectures into a single file. It's the recommended option whenever possible, because simplifies deployment and allows the system to install only the parts needed for each device.

Finally, to publish on the Microsoft Store, the following are used: upload files (.msixupload or .appxupload), which contain one or more packages or bundles along with Symbols Debug files for error analysis. Visual Studio generates them automatically when you package files with the intention of uploading them to the Store.

Create an MSIX package from an existing installer

The classic route for migrating legacy software consists of Use MSIX Packaging Tool as a wizard and follow a guided flow that captures everything the installer does and translates it into MSIX format.

When you start the tool, the first thing to do is select the task type. To generate a standard package, you choose “Create application package” Then you decide whether the capture is done on the computer itself, on a remote machine, or on a local VM managed with Hyper-V.

After preparing the equipment (controller, stopped services, paused updates, etc.), it's time to indicate which installer do you want to convertHere you can work with MSI, EXE, and other installers. App-V 5.xClickOnce, installation scripts, or even leave the field empty if you are going to do a completely manual installation.

If the origin is a MSIThe tool can read internal data (product name, version, publisher, etc.) and automatically populate many manifest fields, saving time and reducing errors. Additionally, if you have associated MST or MSP files, you can pass them as installer arguments.

In the case of a App-V 5.xThe process is usually more straightforward because the package already has a rich manifest. In many situations, simply specifying the App-V file is enough, and the tool translates that information into MSIX format. Note: Versions 4.x are not supported; in that case, it's recommended to revert to the original installer and convert it directly.

To EXE and ClickOnce installersThe format is less structured, and the tool can't extract as much metadata, so you'll have to manually fill in much of the package information (name, publisher, version, etc.). The EXE will still run under monitoring, but the definition work falls to you.

If your installation process is based on custom scripts (PowerShell, CMDetc.), you can specify the command line in the wizard or run it manually during the installation phase. And, if you're interested in having absolutely everything under control, you can also opt for a manual installation, leaving the installer field blank and performing each step yourself while the system is being monitored.

Configure the MSIX package signature

A key point: No MSIX package can be installed unless it is signed with a certificate that the target system considers trustworthy. Therefore, during the wizard's workflow, you will need to choose how it will be signed.

The tool supports several options. You can use the Device Guard signaturewhich is a Microsoft service based on Azure AD and designed for corporate environments where you don't want to manage your own certificate, or you can resort to a own .pfx certificate, common in organizations with internal PKI or certificates from public entities.

There is also the possibility of indicating a unsigned .cer file, actually the packageThis is useful for verifying that the manifest publisher's information matches the certificate that will be used later. Alternatively, you can leave the package unsigned at this stage and sign it later with your usual tools, although this will prevent you from installing it until the signature is applied.

When you sign, it is highly recommended to add a timestamp using an RFC 3161 server. This allows the signature to remain valid even after the certificate has expired, which is critical for long-term installations or audits.

Fill in the package information

After choosing the installer and the signing strategy, you'll reach the screen where you define the MSIX package identityMany fields may be pre-filled, but it's important to review them because they affect both user behavior and experience.

El package name It is mandatory, case-sensitive, and space-free, and corresponds to the identity in the manifest. The end user will not see it, but it is the identifier used by the system. It must be between 3 and 50 characters long, alphanumeric, containing hyphens and periods, and cannot end with a period or coincide with reserved system names (CON, PRN, COM1, LPT1, etc.).

El display name Yes, it is visible in the Start menu and on the settings pages. It can be translatable, supports up to 256 characters, and should be descriptive so that the user can clearly recognize the installed application.

As to editorThere are two values: the technical name (Publisher), which must exactly match the subject of the certificate you are signing with, and the display editor nameThis is what the user will see in the installation dialogs and in the Store. The first is a string with a distinctive name format (CN=, O=, etc.), while the second is a more user-friendly free text.

La self The package uses quad-revision notation of the Major.Minor.Build.Revision type. This value is important for updates, as Windows will use that numbering to decide whether a new package replaces an old one or not.

You can also specify a description optional and the installation location This is where the installer copies the application files (typically Program Files). If the app installs components outside of Program Files, it's a good idea to reflect that here and ensure the path matches during installation to avoid surprises.

Finally, there is a box for Add compatibility with MSIX CoreSelecting the minimum version of Windows you want to support. MSIX Core allows you to install MSIX packages on systems that don't have full native support, slightly expanding the range of machines where you can deploy.

Installation and capture phase

With all the identity information defined, the assistant moves on to the phase of supervised installation, where what the installer does to convert it into an MSIX package is actually captured.

The tool launches the installer (or lets you run it manually) within your defined environment. From there, you should follow the application's installation wizard as you normally would, but with a few recommendations: Use consistent installation paths and create the necessary shortcuts Using the methods you mentioned earlier, create the necessary shortcuts and disable any built-in automatic update mechanisms.

If the application requires multiple installers, additional components, or Prerequisites For example, with .NET Framework 3.5, you can take advantage of this phase to install them, as everything will be captured in the screenshot. The same applies if you need to run scripts or register additional DLLs.

If the installer requires a restart, the tool offers a controlled reset button so that the system restarts and then resumes the conversion process where it left off, without losing the context of what was being monitored.

First-start management and entry points

Once the "visible" part of the installation is complete, MSIX Packaging Tool displays a list of the executables detected during the capture. This is where you define which shortcuts will be exposed as application entries in the Start menu and which one is the primary shortcut.

It is recommended to launch the main application at least once from this screen so that all tasks are recorded. first start (creation of user folders, generation of initial configuration, etc.), which will also be part of the package.

From the same view you can eliminate unnecessary entry points (auxiliary tools, uninstallers, etc.) and select the executable that will act as the main entry. If the main app doesn't appear in the list, you can always manually search for it on your disk, run it, and then update the list of detected executables.

When you click on the next step, the tool will ask you to confirm whether you have finished managing these initial startups or if you need to go back to complete any additional configuration, install more files, or launch other executables.

Service detection and configuration

In recent versions, MSIX Packaging Tool includes a specific page for service reportsIf Windows services were created during installation, they will be shown classified in two tables: included (with the necessary information) and excluded (when data is missing or the service is not compatible with MSIX as is).

Double-clicking on a service will allow you to view and, in some cases, edit fields such as the description, display name, startup account, type of Boot, starting arguments or dependenciesThe service key and the path to the executable are not editable from this interface.

Once you've made the necessary adjustments, you can move the service from the excluded table to the [specific table]. included to include it in the final MSIX package, or leave it out if you prefer to manage it through other means.

Creating, saving, and editing the MSIX package

With all of the above defined, the assistant reaches the step of package creationwhere you choose the folder in which the generated MSIX will be saved and, if needed, the location for a conversion template file that allows you to repeat the process on other machines in a standardized way.

By default, packages are saved in the user's local application data folder, but you can change both the path at that time and the default location from the tool's own settings to adapt it to your workflow.

Before clicking on create, you have the option to open the Package editorThis allows you to review and modify the contents of the MSIX file: included files, manifest, capabilities, access, etc. It is very useful for applying small adjustments without having to repeat the entire capture process.

Upon completion of the creation process, the tool displays a pop-up window with a direct link to the folder where the package has been saved and another link to the log files generated during the conversion (useful for diagnosing problems or documenting the process).

Install and test MSIX packages on other machines

Installing an MSIX package on a test or production machine is quite simple once the system trusts the certificate with which it is signed. In lab environments, this is usually sufficient. import the certificate in the appropriate store and then double-click on the .msix or .msixbundle file to launch the Windows application installer.

On domain-joined machines or those with stricter policies, the usual practice is to distribute the certificate through GPO or management solutions so that all devices recognize the sender as trusted and can install the packages without signature errors.

You can also install and uninstall MSIX from PowerShell, which is very handy for automating tests or controlled deployments. Commands like Add-AppxPackage o Remove-AppxPackage They allow you to handle packages in a scriptable way, and with Get-AppxPackage You can view information about the installed apps.

Once installed, the application no longer appears as a classic program in "Programs and Features", but as a modern app in the UWP environment, usually hosted in C: \ Program Files \ WindowsApps, with the corresponding isolation and permission model.

Using Visual Studio to create MSIX packages

If the application is under development and you're using Visual Studio, the easiest thing to do is Generate the MSIX directly from the projectespecially in UWP applications or in Windows application packaging projects that wrap a Win32 app.

The heart of this process is the archive Package.appxmanifestAn XML file that describes identity, capabilities, icons, screen orientations, extension declarations, and other details necessary to build the package. Visual Studio offers a graphical designer for editing it without manually editing the XML.

From the Solution Explorer you can open the manifest by double-clicking on it Package.appxmanifestIn the different tabs you define, for example, the visual resources (icons, logos, splash screens) or packaging parameters, including the certificate with which the MSIX will be signed.

If you're going to publish on the Microsoft Store, it's recommended to associate your project with an app in the store using the option Publish → Associate the application with the StoreThis automatically synchronizes certain packaging fields (identity, publisher, etc.) with the information in the Partner Center.

Once the manifest is set up, you can launch the wizard to Create application packages From the project's Publish menu. There you choose whether the destination is sideloading (distribution outside the Store) or Microsoft Store, the architectures to include, whether a bundle will be generated, and how the package will be signed.

Uploading and submitting files to the Microsoft Store

When your goal is to distribute the application through the Microsoft Store, in addition to the package itself you need a upload file .msixupload or .appxupload, which packages the bundle and symbols necessary for telemetry and fault analysis.

Visual Studio can automatically generate this file if you select the option to create packages for the Microsoft Store in the wizard. In that case, once the creation process is complete, the .msixupload file will be available in the project's output folder, ready to be validated and uploaded to the Partner Center.

If for any reason you need to build the upload file manually, you can group one or more of them into a folder. .msix packages or .msixbundle bundles along with your .appxsym symbol file, compress them into a ZIP file and then change the extension of the resulting file to .msixupload or .appxupload.

In these Store publications, it is very important to include public symbols if you want to take advantage of the capabilities of failure and performance analysis offered by the Partner Center; otherwise, debugging information will be limited.

Validation with the Windows Application Certification Kit

Before uploading any package to the Store (and also for serious internal deployments) it's good practice to run the Windows App Certification Kit (WACK), which runs a set of automated tests on the package.

From the Visual Studio wizard itself, when you finish creating packages, you can directly launch WACK on the local team or on a remote device with the kit installed. The tests review aspects such as performance, API usage, security, and compliance with platform requirements.

If you have a remote device running Windows 10, you can enable it for developmentInstall the Visual Studio remote tools and certification kit on it, and then use the option to Remote machine in the wizard to run the tests from your development machine against that team.

Once your package passes WACK testing, you're in a good position to submit it to the Partner Center. The generated .msixupload file is typically located in the solution's AppPackages folder, with a name that includes the version and supported architectures.

Automate submissions to the Microsoft Store from Visual Studio

In recent versions of Visual Studio it is possible to go one step further and Automate submission to the Microsoft Store directly from the IDE, once the package has passed WACK validation.

To do this, you need to have your Partner Center account associated with a Azure Active Directory tenantand register an Azure AD application with administrator permissions for shipments in that account. From the Partner Center dashboard, you will obtain the tenant ID, customer ID, and a secret key.

With these credentials configured in Visual Studio, at the end of the package creation wizard you can select the option to automatically send to the Store after validationFrom that moment on, once WACK finishes, the IDE itself will start the sending process and you can follow the progress from the check and publish window.

This workflow is especially useful in development teams that do frequent deliveries to Store and want to reduce manual steps, while maintaining the security that Azure AD provides in authentication.

MSIX app attach and VHD/CIM containers

In desktop virtualization scenarios (multi-user Windows 10/11, Azure Virtual Desktop, etc.), MSIX becomes even more interesting thanks to MSIX app attach, a technology that allows applications to be decoupled from the base image and loaded from containers.

In this model, instead of installing the application within the OS image, the MSIX package is transformed into a VHD, VHDX or CIM containerThese containers are mounted at runtime and the system "attaches" the application to the user's profile, reducing the image size and simplifying version management.

CIM files rely on Composite Image File System (CimFS)which offers faster mounting and lower resource consumption compared to classic VHDs. Microsoft provides tools like MSIX Manager Tool to manually convert MSIX to VHD, and there are third-party utilities (MSIX Hero, AppVentiX tools, etc.) that simplify the process and integrate it into larger workflows.

However, to take advantage of MSIX app attach, you need to meet certain Windows version requirements (for example, Windows 10 2004 or later) and have valid certificates that allow the system to trust the signed applications that will be mounted as containers.

Together, MSIX, the packaging tool, Visual Studio, and app attach form a fairly powerful ecosystem that allows modernize deployments, reduce application conflicts, and improve management in both traditional and cloud environments, as long as you dedicate some time to understanding each piece well and defining a packaging strategy consistent with your needs.

Related article:

Enable developer mode in Windows 11 and safely test unsigned apps: Complete guide with risks, Device Portal, WSL, and drivers

Isaac

Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.