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. MSIX is the result of their experience with MSI and App-V packages and the Desktop Bridge program.

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 (SCCM, 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. In general, MSIX packaged Win32 apps currently only work on Windows 10, running x86 or x64 Intel/AMD processors.

There is one exception, the Always-Connected-PC devices, running Windows 10 in S mode, where Win32 apps run on ARM devices with emulation support (included in the OS) and specific ARM CPUs.

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.

As MSIX is still in development, we can still expect changes, but until then, you can use the hybrid-solution adopted by the App-V folks, where drivers still get deployed using our old friend, the MSI package.