MSIX Technology Fundamentals

What is MSIX

Microsoft presented MSIX in 2018 as an improved version of the AppX package (initially used only for UWP apps) to better support traditional desktop applications on Windows 10.

Structure-wise, an MSIX package is very similar to an AppX or App-V package. It is basically a zip package that contains your application files and some configuration XML files.

While MSIX is designed to support the latest development trends, it also comes with significant support for older Win32 (which includes traditional x86 and x64 unmanaged-code apps and DotNet Framework-based applications), e.g., the standard desktop applications that we’ve been using all of these years. Now, you can package your standard desktop application using the new MSIX format and deploy it using the tools you already have (MECM, Intune, etc...).

You can also take this new package and publish it in the Microsoft Store or for direct download from a website while leveraging all the new advantages from the modern Windows APIs (if the app is still in development).

Not all Win32 applications can be packaged and launched inside an MSIX container. Microsoft has prepared a list of requirements - you can check this article to make sure your application is suitable for migrating to MSIX.

The MSIX Container

The application delivered with an MSIX package runs on systems inside a container. This container, sometimes called "Helium" by Microsoft, is a lightweight version of the containers on Windows Servers that are meant to be used by services such as Docker. As you will see, we will sometimes refer to this runtime environment as the MSIX Runtime.

Depicted below, you will find that the MSIX container can bring together:

• MSIX packaged applications (full trust model),
• Applications packaged as Desktop Bridge apps (files and registry virtualization),
• Applications packaged using UWP apps (the capability model).

These different programming models share the container, but do not necessarily support the same features.

Classic Win32 apps converted to MSIX have runtime functionalities that UWP apps do not have. This is because they declare a special capability called “runFullTrust” in the manifest. The name refers to the trust level granted within the container and is not related to UAC elevation on the system, so it may be a bit misleading.

While the apps we deal with these days are either traditional Win32 based code or UWP based code, we're noticing a shift of direction. Now, developers with source code access may build a hybrid app that leverages both platforms, as long as they build it as an MSIX package. As it is more of a bolt-on approach for the developer, today we think of this as a hybrid, but eventually, we will likely begin to think of these as the “native MSIX apps”.

Classic Win32 MSIX packaged applications will still run only on desktop devices, and they don't “become“ universal apps simply because we are packaging them in a new format. These converted apps are still compiled for x86 and x64 processors and need all of the traditional Windows dlls, so they cannot run on non-Windows tablets/phones or other non-supported devices.

System Interfaces

The MSI or EXE installation of a traditional application does much more than lay down files and registry items. During the integration of an application in the system, the installation touches various system locations - which could negatively impact other existing applications and the system itself.

Adding an MSIX or a UWP package to the system is different. For the most part, everything exists within the container and very few resources are exposed outside of it. The resources that are exposed are defined in the package manifest. Because of this, you have more control over possible impacts on the system through the AppInstaller software when adding or removing the package.

The following diagram indicates the OS resources supported at this time (for a Win32 application) that an MSIX package can install. On top of these, from your source code you can enable your application to also use the new native UWP components (app services, background task, etc) to better integrate with the OS or other applications.

Here is a summary of what an MSIX package can natively install today:

• Files
• Registry (available as a package Application Hive only seen within the container)
• Fonts
• Tiles (a replacement of the common shortcuts you’ve created so far)
• Services (which get installed and run outside the container)
• COM
• File Associations
• URL Protocols

One important thing to understand is that all of the above resources are defined in a completely new manner for MSIX packages. Gone are the days when you could write to the registry to define a file type association or integrate a COM component. You can read more about it in our “AppxManifest.xml aka the Package Manifest” chapter.

If you're looking for drivers, these are not supported directly in MSIX packages but are referenced as an external component. Microsoft recommends that all drivers are uploaded to the Microsoft Store by the hardware providers, so the OS manages their installation automatically for the end-user.

The list of supported resources is constantly updated by Microsoft, check Advanced Installer Blog - MSIX Support Windows article for the latest version.

The MSIX Package Layout

The image below shows the most common and basic MSIX package layout. You can see a similar list of resources if you extract an MSIX package using makeappx.exe or using a tool like 7-Zip.

Extracting the package this way makes it quick to inspect its contents without using a dedicated editor/viewer. The structure you see below is exactly the same one that will be expanded by the OS in the installation folder, under %ProgramFiles%\WindowsApps.

If you have experience using App-V, you can notice the similarities between the two package formats. Unlike App-V, the MSIX package does not come with additional external configuration files.

Let’s have a quick look at each of the main areas from the package.

Assets - As the name implies, this folder is where all the app’s graphics assets should be found. These are usually generated/extracted automatically by the packaging tool.

MSIX packages are much more aware of the graphical capabilities of a device and can carry graphical assets for any screen size and DPI, while optimizing their delivery.

VFS - This folder normally contains the application binaries. DLLs, EXEs, config files, and so on. The VFS and Assets folders are also known as the app payload.

At installation time, the files from the VFS folder are overlaid on top of the system’s known folders. Your application will perceive these files to be in the well-known system locations (like Program Files or System folders), when in fact they are all found in the redirected locations inside: %ProgramFiles%\WindowsApps\package_name\VFS.

Nothing gets written in the installation folder at runtime.

Any configuration files that will need to be updated by your application will actually be redirected by the third layer (application files and settings). You can read more about this in our VFS chapter.

In some cases, the application might fail to run from the VFS folder. In this case, the packaging tool should give you the option to place the application resources directly into the package root.

Registry.dat - This file stores the HKLM and HKCU registry entries of the app. Some packages also have additional .dat files that contain a copy of the user registry entries (User.dat), and the equivalent of the HKCR view (User.Classes.dat). You can read more about this in our Registry chapter.

This means that your registry settings from the package are no longer installed directly on the machine, polluting the system registry hives. Instead, you have an Application Hive, only available to the application running inside the container with your package. Just as with the VFS, the OS maps the registry from your package on top of the registry from the system, making the application see a unified version of all the registry hives.

Your app can no longer use the registry to share data stored in application-specific folders with other applications (since these registry entries are only visible from inside the container of your app). Also, you can no longer define FTAs or other similar resources by manipulation of the registry alone. That is now all done through the AppxManifest.xml. A good repackaging tool, however, will use the older style registrations to automatically trigger the addition of the appropriate entries into the manifest.

If a “.dat” registry hive file is present in an MSIX package it indicates the packaged application is a Win32 one, not a full UWP application. Only MSIX packages for Win32 apps can contain registry “.dat” files.

Resources.pri - This file contains app resources, like localized strings and paths for additional resource files. Packages contain one file per language.

AppxManifest.xml - This XML file is the core resource of an MSIX package, as detailed in the following chapter. It contains all the information required by the system to identify, install, and run the application.

This is where you will find the:

• Applications installed by your package
• Package declarations & capabilities (FTAs, Services, etc.)
• Dependencies for other MSIX packages (redistributables, or the package that a modification package layers onto, etc.)

The package manifest is automatically generated by the packaging tool you use. You can also create/edit it manually and use makeappx.exe to manually package the extracted resources into an MSIX.

While general compression tools, such as 7-Zip are practical for viewing the MSIX package contents, if you just rename a file from .7x to .msix, it will not create a valid package. Only makeappx, or a tool that uses makeappx under the covers, can generate a valid MSIX package.

AppxBlockMap.xml - This is a file generated at build time, by the packaging tool, it contains a list of all the app’s binaries and their hashes. It is used by the system for integrity checks and for performing differential updates (lowering bandwidth usage by downloading only the changed files), as well as single-instance storage (across all packages installed on the system).

AppxSignature.p7x - This file stores the digital signature information for the package contents.

Just like the block map file, it is automatically generated by the packaging tool.

All MSIX packages must be digitally signed with an SHA-256 code signing certificate.

If you build the package and deploy it internally in your company, you can also use a self-signed certificate (that was previously installed on all the machines where the package will be deployed, otherwise the package deployment will fail).

All the packages from the Microsoft Store are digitally signed with a Microsoft certificate (not the vendor’s certificate) which is trusted by the OS.

Digital Signing is a completely new requirement for application packaging (which was optional for MSIs). We wrote an entire section on this topic to help you employ a streamlined process across your entire packaging team.

[Content_Types].xml - Contains information about the types of content in an MSIX package, used by the system at installation. This resource is also generated automatically by the packaging tool.

Branding your MSIX Installer Package

Another new addition to MSIX in recent years is the ability to customize the look and feel of your package when installed using the AppInstaller. Some organizations will want to leverage this to “brand” their packages to make it easy to understand that it was repackaged internally and is not directly from the vendor.

The customization is triggered by an additional folder placed at the root level of the package, along with an XML file that contains the customization. The filepath will be:

Msix.AppInstaller.Data\MsixAppInstallerData.xml

The customizations supported are limited. For example, although you can specify colors, these colors are treated as hints and the software appears to attempt to follow some accessibility guidelines so getting your corporate colors to be used correctly might be challenging.

More details on adding this branding file may be found at the Microsoft documentation How to create a custom App Installer UX - MSIX | Microsoft Learn .

According to Microsoft, this App Installer feature has been temporarily rolled back and will not work right now. Please check back later for further updates as we plan to bring this feature back.

Microsoft Documentation and Community Sites

If it is only one link you learn one from this book, it should be this one: “http://aka.ms/msix”. This is Microsoft's landing page for all things related to MSIX. Currently, this redirects to https://learn.microsoft.com/en-us/windows/msix/

From this page, Microsoft provides access to documentation, downloads, tutorials, videos, and the MSIX community known as “Tech Community” (the replacement of the old TechNet forums), and more.

OS Version vs MSIX Functionality

The public rollout of MSIX started with Windows 10 version 1709. Ever since, Microsoft has continuously improved the platform with new and updated features.

To get an always-up-to-date reference of all the features listed in this book, you can bookmark the following URL on your browser:

“advancedinstaller.com/msix-support-windows”

This online list will be constantly updated by the Advanced Installer team.

By the time you read the second edition of this book, most Windows 10 enterprise users should be running Windows 11, as Windows 10 is nearly end-of-life as we are writing it.

Considerable extensions added to MSIX require a minimum OS version that is somewhere between 1709 and the Windows 11 releases. Through most of this book, we will assume that you are running some form of Windows 11 (build 20000), and try to only mention version specifics when necessary. A summary of the major OS version dependencies is offered here for historical purposes.