Packaging Windows desktop apps with MSIX

In this article we will talk about what MSIX is, the structure of a package, the type of packages you can create, and how to create a new one and publish it using Visual Studio.

A brief introduction to MSIX

Nowadays, if you want to deploy an application, your best option is MSIX.

MSIX is a Windows app package format that, as the documentation states, combines the best features of MSI, .appx, App-V, and ClickOnce to provide a modern and reliable packaging.

It is the best choice if you want to package and deploy features of Win32, WPF, and Windows Forms apps. It also includes UWP applications.

Moreover, MSIX is reliable, it reduces the impact of network bandwidth by downloading only the 64k block. With MSIX, there is no duplication of files across apps, and Windows manages the shared files across apps.

As declared in the documentation, some benefits of MSIX concerning app containers are:

Apps that are packaged using MSIX run in a lightweight app container. The MSIX app process and its child processes run inside the container and are isolated using file system and registry virtualization. All MSIX apps can read the global registry. An MSIX app writes to its own virtual registry and application data folder, and this data will be deleted when the app is uninstalled or reset. Other apps do not have access to the virtual registry or virtual file system of an MSIX app.

MSIX package structure

An MSIX package is divided into two main blocks: the package payload and the footprint files.

App payload

The app payload files are the code files and assets created during the application’s building.

Footprint files

The footprint files are the AppxBlockMap, the AppxSignature, and the AppManifest. All MSIX files require to be signed before install. The AppxSignature and the AppxBlockMap work together and allow us to install and validate our package. You’ll find more information about these two files in the Microsoft documentation.

App package manifest

The package manifest is an XML file that contains information about package identity, package dependencies, required capabilities, visual elements, and extensibility points. Every application package includes only one package manifest file. Because it is signed during the package signing operation, it can’t be modified. Modifying the manifest invalidates the package signature. An in-depth article about this topic can be found in the next post.

Types of app packages

There are several types of packages that you can pick, depending on your needs. They are:

• App package (.msix or .appx): this type of package is a single package containing your application and its resources, targeted at a single device architecture.
• App Bundle (.msixbundle or .appxbundle): app bundles can contain multiple application packages for different device architectures (x86, x64, and ARM). App bundles allow your application to be available on the widest possible range of devices.
• App Package Upload File (.msixupload or .appxupload — store submission only): a single file that contains multiple app packages or an app bundle. App Package Upload File contains a symbol file that is automatically created when you package your application to submit it to the store. The symbol file analyses the performance of your application.

Creating an Application Packaging Project

First, we will need to create a new Application package project, to do so, let’s perform the following steps.

• Open the solution that contains your application, and Add a Windows Application Packaging Project.

• Select the Target Version of the project.

• Right-click in the Applications folder of your newly created project, and click on Add Reference. Select your application project and then click on the OK button.

• You can select multiple desktop applications in your package, but one of them needs to be selected as the entry point. To do this, right-click on the application that you want users to start when they run your application, and then click on Set as Entry Point. Selecting multiple applications in your package can be used to distribute them all as one and the secondary applications will have to be invoked from the one selected as an entry point.

• Build and correct the errors if necessary.

Publishing your package using Visual Studio

Now that you have your package ready you will need to publish it, to do so you need to perform the following steps.

• Right-click on your package project, and select Publish and then Create App Packages option.
• Then select the distribution method (we used the Sideloading option) and click on the Next button.
• Select the signing method. You can generate a test certificate by using the PowerShell commands found here.

• Finally, select and configure your packages, and press Create.

Summing Up

MSIX is too big to be discussed in only one article, so this is the entry point to this technology. You can read more in Microsoft documentation starting here. Thank you for reading.