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.

Remember. 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),

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.

Remember. 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.

Tip! 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.

Note! 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.

Remember. 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.

Next Page ›

Contents

The MSIX Package Layout