For over two decades, application packaging has been a cornerstone of technology’s evolution.
Think of it like a supermarket warehouse where every item is meticulously boxed and bagged for safe shipping. Packaging protects the product, alleviates unnecessary expenses, and streamlines distribution processes.
Groceries? Really? How does this connect to MSIX?
Application packaging has been an integral part of computing since the dawn of programmable machines.
- From the punch card boxes of the 1950s and 1960s
- To the cassette tapes and floppy disks in the 1970s and 1980s
- Then, embracing the era of files, folders, and icons in the 1980s and 1990s
- And landing in the era of CD-ROMs in the 1990s
Ah, good ol’ CD-ROMS. Remember when an MS Office Pro installation meant juggling up to 40 floppy disks? The CD-ROM era was a wild and welcome change!
As we turn the page to the present, MSIX emerges as a groundbreaking evolution in this lineage.
This comprehensive guide explores what makes MSIX an application packaging game-changer and why you should make the switch.
What is MSIX?
First announced in 2018, MSIX is the latest application packaging format from Microsoft. Designed to simplify application deployment and management, it leverages containerization to bring a number of benefits to the Windows experience.
Aimed both at Independent Software Vendors (ISVs) and the enterprise, the format is positioned to ultimately replace legacy formats such as Windows Installer (MSI) and setup executables. Although, uptake from both markets has been slower than some may have anticipated.
Sometimes referred to as the next version or evolution of MSI, it’s more accurately described as the next version of APPX–the format used in the Windows Store. As we’ll see later inside an MSIX package, there is almost no difference between the content of an APPX file or an App-V file.
MSIX vs MSI: The Key Differences in Formats
MSI packages, which install locally on a device, place file and registry resources where they’re needed on the machine.
Over time these resources, Whether still in use or left behind after removing the original application, these resources lead to Winrot–the gradual loss of performance on a Windows system.
MSIX by contrast is a containerized format. This means its payload doesn’t get spread across the OS. Instead, all files and registry keys are stored in a container to be virtualized. To the application, it looks like the files are in the expected file system or registry locations.
Technical Details of MSIX
As already mentioned inside an MSIX, there is very little difference to an App-V package. The main difference is how the payload is deployed to a machine.
While MSIX is a containerized format even when not in use, App-V only gets virtualized at runtime. That’s when running the application processes are isolated in the App-V virtual environment.
The rest of the time, however, the payload of an App-V package is exposed and accessible in Windows Explorer and the Registry. MSIX and App-V also share similar limitations because of being containerized/virtualized formats. Though App-V handles some of these limitations better than MSIX does at the moment.
MSIX File Formats and Understanding the MSIX File Structure
There are two parts to the MSIX file: the package payload and the supporting files required by all MSIX packages. The package payload includes all the application’s files and other assets created as part of building an MSIX file.
The supporting files required by all MSIX packages include:
- AppxManifest.xml: this file contains all the information required to install, use, and manage an MSIX package. In addition to information about identity, dependencies, required capabilities, visual elements and extensibility points, you update the AppxManifest.xml file when you need to invoke the Package Support Framework.
- AppxBlockMap.xml: the blockmap file describes the payload of the MSIX package to secure the package integrity. It supports downloading and validating the package incrementally and enable differential updates.
- AppxSignature.p7x: all MSIX packages must be signed before installation. During the signing process, you generate the AppxSignature.p7x file, which, along with the AppxBlockMap.xml file, validates the package integrity upon installation.
Differences and Roles of .msix, .msixbundle, .msixupload, and Other Related File Extensions
In addition to the MSIX file, there are other related file formats you may encounter. These are typically related to ISV applications or appear if you are publishing applications to the Microsoft store.
The .msix file contains everything required to secure, install, and update the application contained within the MSIX package.
A .msixbundle file contains multiple MSIX packages, each built for a different Windows architecture (x86, x64 or ARM). The bundle file additionally describes which MSIX package to install on which architecture. You can generate MSIX Bundle files using the MakeAppx.exe tool.
For submission to the Microsoft store you can use an .msixupload file, which can contain multiple MSIX packages or an MSIX bundle. Usually, you can automatically create an MSIX Upload file using Visual Studio if you are packaging an app with the intention of publishing it to the Microsoft store. You can also create the file using the MakeAppx.exe tool.
Comparing MSIX With Other Formats
APPX as a format was never targeted at the enterprise for repackaging applications. This is because it wasn’t meant for Win32 applications, which make up a large majority of desktop applications we know in the enterprise.
APPX packages, which are also containerized, had more limitations than App-V. The idea was to develop ISV’s apps to be “modern apps” for a “modern OS, which mitigates these limitations.
When APPX was first released, MSIX was essentially an APPX package with a different file extension. There is still evidence of this today in the tooling around MSIX, such as:
- AppxManifest.xml file in the MSIX
- MakeAppx.exe to generate an MSIX package
- Add-AppxPackage and Remove-AppxPackage PowerShell commands to install and uninstall MSIX packages
MSIX makes it possible for enterprises to repackage their applications using the MSIX Packaging Tool.
Repackaging to AppX was possible via a utility called the Desktop Bridge but again this was never targeted at the enterprise. With the MSIX Packaging Tool existing in Win32 applications in MSI, App-V and Setup EXE formats can be captured in or converted to the MSIX format.
Much like with Windows Installer over 20 years ago, MSIX now presents the opportunity for enterprises to align their application packaging strategy with a format used by ISVs. This enables greater consistency in the management and delivery of repackaged and Commercial Off the Shelf (COTS) applications.
3 Reasons To Repackage Applications To MSIX
Repackaging can simplify the management and deployment of applications in your environment. This is especially the case for older applications without unattended install options or applications that require post installation configuration that is not configurable via the installer.
The package format itself can bring additional benefit, here are some reasons to consider MSIX:
1. Prevents Winrot
MSIX is a fully containerized format, meaning both the files and registry keys associated with the package are always separated from the OS.
Unlike with older package formats, these resources do not accumulate over time, thus degrading the performance of devices.
2. Bandwidth Optimizations
Allows MSIX packages to be downloaded and validated incrementally. This also allows for differential updates between one version of MSIX and the version that should be downloaded next.
3. Disk Space Optimizations
Ensures there is no duplication of files in MSIX packages. If two MSIX packages contain the same file, that file lays down once on the device but is shared between both apps by creating hard links.
If one of the apps updated that file, it’s no longer the same file. From there, each would use the appropriate version of the file.
This could be very useful when deciding to deploy runtimes locally in more traditional formats or bundle them in the MSIX package. These runtimes would not take up additional space when the packages are deployed to the same device.
MSIX Compatibility with Older Windows Versions
Microsoft has recognized that most enterprise applications are still traditional Win32 applications. This is likely to continue for years to come.
Because of this, applications will come up against MSIX limitations such as:
- Inability to write to the package install location
- Certain registry actions and launching applications with parameters
- Specific working directory
To overcome these issues, they released an open-source project called the Package Support Framework (PSF). PSF detours technology and allows fixes to hook into an application when it is launched. It redirects calls where necessary to mitigate an issue.
To implement the PSF in the package you will need to include the following in the root of your MSIX package:
- The PSFLauncher exe: the executable that initially gets launched and loads the required fixup before launching your application and injecting the fixup. There is a 32-bit and 64-bit launcher depending on the architecture of the app being fixed. Be sure to include the correct file.
- The PSF Runtimes: these too are architecture dependent
- The Fixup Dynamic Link Library (DLL): this file provides the fixup. There are different DLLs for different fixups. You can include more than one fixup at a time in your package.
- A JSON config: this file tells the PSF Launcher which fixups to apply, how to apply them, ands which applications to apply the fixups to.
The simplest example of this is the file redirection fixup, which can be used when an application tries to write for its install location.
For this fix-up, define the application it needs to be applied to, the folder that the application is trying to write to, and the file(s) that should be redirected.
This would look like the config.json file below. It redirects any attempts by MyApp.exe to write to a log file in the “My App” folder.
Further information on the Package Support Framework can be found on Microsoft’s Package Support Framework or Github’s Package Support Framework.
The MSIX Container and Its Benefits
The MSIX Container ensures that the application and child processes run in isolation from the operating system and other applications using file and registry virtualization.
When installed, the payload of an MSIX lays down in C:\Program Files\WindowsApps\package_name, including any files that will be part of the VFS as well as registry .dat files for any required registry keys.
This means when the MSIX package is removed and the “package_name” folder is deleted, the application has been cleanly removed from the device. Any changes made to the virtualize file system or registry are deleted as well.
Storing the registry keys for an MSIX package in .dat files so they’re virtualized at runtime has an additional benefit. Windows starts all the registry keys under HKLM and are enumerated. The more registry keys present the longer it will take to start.
If applications leave HKLM keys behind when uninstalled, they continue to make start times slower even after the application is gone. App-V doesn’t solve this problem because once installed, all the HKLM registry keys destined for virtualization are stored in the registry.
The MSIX Shared Container Explained
A shared package container allows MSIX packages to run in the same container. This enables them to see each other’s processes and a merged view of their virtual file systems and virtual registry. Shared containers are only available to enterprise editions of Windows and require admin privileges to use.
You can configure shared containers by defining an xml file. That gives the shared container a unique name and lists the packages that should run in that shared container. Unlike App-V connection groups, the apps running in the shared container don't need installation to deploy to a device.
The shared container definition file is deployed to a device using the PowerShell command:
Add-AppSharedPackageContainer -Path C:\MyFolder\ContosoTestContainer.xml
Similarly, you can reset and remove the shared container with the appropriate PowerShell commands:
Reset-AppSharedPackageContainer -Name ContosoTestContainer
Remove-AppSharedPackageContainer -Name ContosoTestContainer
For shared containers, an app can only be part of one shared container.
If you add a pre-requisite package to a shared container, all other packages needing that pre-requisite have to be part of the same shared container. They also need to co-exist with each other.
The shared container might offer a more streamlined alternative to deploying pre-requisites locally in a traditional packaging format. But you still might consider capturing pre-requisites as part of the package that depends on them.
The single instance of files means even if multiple packages contain the same prerequisite, you won’t be losing disk space.
Introduction to MSIX Core
Windows 10 1709 and later supports MSIX. Since no one services 1709 any longer, everyone should be using a version of Windows 10 that supports MSIX.
If you’re running a version of Windows that doesn’t support MSIX, and you don’t want to maintain an MSIX or non-MSIX package, consider MSIX Core. It allows you to deploy MSIX packages to:
- Windows 7 SP1
- Windows 8.1. Support versions of Windows Server (with Desktop Experience),
- Windows 10 releases prior to 1709
Support for MSIX Core must be added to the MSIX package. In the MSIX Packaging Tool, select the checkbox when creating the package or updating the MSIX package manifest of existing packages.
MSIX Core does not provide the container benefits of native MSIX. It’s simply a mechanism for deploying the payload of an MSIX to an operating system where MSIX is not supported.
The Importance of MSIX Signing
All MSIX packages must be signed with a valid code signing certificate before they can be installed.
For ISVs who put their apps into the Microsoft Store, that process automatically signs the MSIX for them. For enterprises creating their own MSIXs, they need to provide a valid certificate to sign their MSIX packages before deployment.
Enterprises have two options:
- Buy a code signing certificate: Windows trusts certificates from certified providers.
- Create a self-signed certificate: if you create a self-signed certificate, you should distribute it to all your devices
Whichever option you choose, use timestamping to ensure your signed MSIX packages will still be useable even if the certificate expires. For example, self-signed certificates created through PowerShell are only valid for a year.
Simply put, the time-stamping authority shows that your certificate was valid at the time of signing.
As a last note, whenever an MSIX file is edited, it must be resigned by the packaging tool used to edit the MSIX or with a utility like SignTool.exe which can be found in the Windows SDK.
How To Install and Uninstall MSIX packages
Enterprises can distribute MSIX packages via traditional methods such as Endpoint ConfigMgr and Intune. They can also deploy to cloud solutions like Azure Virtual Desktop or Windows 365 Cloud PC.
If you are just getting started with MSIX, you can install packages using App Installer. It allows you to install MSIX by double clicking on it. The App Installer has a simple GUI interface but doesn’t let you configure the MSIX in any way. If you don’t have the App Installer on your device, you can install it from the Windows Store.
To remove an MSIX package, right click on the Start Menu and select “Uninstall” or find the app under Apps & Features and choose the uninstall option.
Alternatively, you can use the Add-AppxPackage and Remove-AppxPackage PowerShell commands.
The Future of MSIX: What’s Next?
It is clear there are benefits of MSIX but as with many things, adoption will be key, both from the enterprise and ISVs alike.
MSI gained great traction in the enterprise as a repackaging format and vendors followed suit which is why it is still such a prevalent format. App-V also gained significant traction in the enterprise, but it could never fully replace MSI and didn’t appeal to vendors.
At a minimum, MSIX has the potential to gain significant traction in the enterprise. Anyone using App-V inherently made headway on an MSIX journey thanks to ISV uptake of the format. MSI and older formats in the enterprise will exist for years to come.
- Andrew Mason, Solutions Engineer at Rimo3
As enterprises and ISVs explore this format and encourage the technology to mature, you’ll see MSIX used to deliver more applications.
A Quicker Solution for Application Modernization Packaging
The application modernization and packaging process can be cumbersome. Rimo3 Cloud can analyze your application portfolio’s MSIX suitability through automation.
The unique Intelligent Smoke Test can convert application packages and run tests to ensure they work in the new format.
Depending on the project, you can automate testing for thousands of applications in hours or days.
Trade manual application testing for automation.
