MSIX Modification Packages

MSIX Modification Package is a type of MSIX package format introduced by Microsoft with the goal of decoupling customizations from the main application. Launched with the release of their MSIX packaging format, the MSIX Modification Package is an MSIX package meant to store the customizations of the application.

Is the MSIX Modification Package the new MST equivalent?

If you are familiar with Windows Installer technology, then you know that, just as with the MSIX Modification Packages, Transform files (MSTs) are meant to store the customizations of an MSI package. But that is as far as the similarities go for them.

MST files can be applied to the base MSI only at the time of installation and through the same msiexec command.

For a broader perspective, let’s compare MSIX Modification Packages with Windows Installer Patches (MSPs). Although an MSP is applied to the MSI in the same way that an MSIX Modification Package is applied to the MSIX - there are two differences:

• It cannot be installed on its own
• It can be applied at any time (at installation time or later).

MSPs are meant to store other resources (bug fixes, security updates, and hotfixes), but not customizations.

In summary, the MSIX Modification Package is similar to MST because they both are meant to store customizations and, because they both are packaged separately from the target package.

A deep dive inside the manifest

This manifest section is always located in the AppxManifest.xml file of a modification package.

<Properties>
    <rescap6:ModificationPackage>true</rescap6:ModificationPackage>
</Properties>

Going forward, there is a MainPackageDependency entry which is included within the Dependencies section of the MSIX Modification.

Package manifest file, but not in the manifest file of the target application. It is called “TargetAppSample” in our example below.

<Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17701.0" MaxVersionTested="12.0.0.0"/>
    <uap4:MainPackageDependency Name="TargetAppSample" Publisher="CN=Contoso Software, O=Contoso Corporation, C=US" />
</Dependencies>

This comes with two attributes:

• Name – it must match the identity Name of the target MSIX application.
• Publisher – it does not have to match the identity Publisher of the target MSIX application and this information could be missing if the publisher is the same.

Also, since the MSIX Modification Package does not contain a full application, it does not have an entry point. In turn, there is no Application node within the manifest file of the MSIX Modification Package.

How does an MSIX Modification Package work?

One of the nice perks of decoupling the customization from the main application is that you will have two separate packages with no explicit relationship between them. And, since it is a separate package, you will not have to recreate the MSIX Modification Package with the same customizations each time there is a new update of the main application –obviously, as long as the customizations stored in the MSIXModification Package are still applicable.

Not only do you not need to recreate the MSIX Modification Package, but there is no need to remove and reinstall it when a new update of the main application comes in. The customization stored in the MSIX Modification Package will apply successfully to the new MSIX package for the main application once the updated target MSIX package gets installed.

However, there's a small catch. The MSIX Modification Package doesn't contain a full application, thus it can't be installed on its own. The MSIX for the main application is required to be installed on the device prior to the MSIX Modification Package installation. If you mix-up the steps, you will be presented with an error like the one shown below:

When an MSIX Modification Package is installed, its content will overlay (at runtime) on top of the resources from the target MSIX in a way that it will look like one application for the operating system and the main app.

Let's do a small exercise. Imagine we have an executable file that reads the content of a .config file placed next to it and displays the outcome on the screen. Our example application is being packaged into MSIX.

Now, we want to replace the .config file with a new one (customized for our enterprise environment) using an MSIX Modification Package.

Now, take the MSIX Modification Package created with the new .config file included within and install that on a device where the target MSIX package is installed. App Installer will prompt a message to let you know that it will modify the target application.

Once the MSIX Modification Package is installed, if we launch our application, the executable will now read the content of the new .config file included within the MSIX Modification Package.

If you go to “App Settings” for the MSIX Package, you should find the MSIX Modification Package listed under the “App add-ons & downloadable content” section, here is an example for a target package called “MyApp” and its modification package “MyModificationPackage”:

Or you can achieve the same output by using Get-AppXPackage PowerShell cmdlet:

PS C:\Windows\system32> get-appxpackage -name "My Company. MyApp"


Name			: My Company.MyApp
Publisher		: CN=Horatiu Vladasel
Architecture		: X64
Resourceid		:
Version			: 1.0.0.0
PackageFullName		: My Company.    
                          MyApp_1.0.0.@_x64_r21nowlrc5s2y
InstallLocation		: C:\Program Files\WindowsApps
                          \My Company. MyApp_1.0.0.0_x64_r21nⓇw1rc5s2y
IsFramework		: False
PackageFamilyName 	: My Company. MyApp_r21n@wirc5s2y
Publisherid 		: r21now1rc5s2y
IsResourcePackage	: False
IsBundle		: False
IsDevelopment Mode 	: False
NonRemovable 		: False
Dependencies 		: {MyCompany.MyModificationPackage
                          _1.0.0.0_neutral _r21n@wirc5s2y}
                        
IsPartiallyStaged 	: False
Signaturekind 		: Enterprise
Status			: OK

Additionally, you can get a list of all installed MSIX Modification Packages using the following PowerShell cmdlet:

Get-AppPackage -PackageTypeFilter Optional

The main MSIX and the MSIX Modification Package are installed in separate folders under “C:\Program Files\WindowsApp”. When the application is launched, it will consider (“see”) both packages within a single container.

For debugging, you can launch an external EXE (eg.: regedit.exe or cmd.exe) inside an MSIX container using Invoke-CommandInDesktopPackage PowerShell cmdlet.

Alternatively, you can use Hover - a free tool, built by the Advanced Installer team, which allows you to launch natively installed applications inside an MSIX container with just a double-click.

Basically all you have to do is to launch a cmd.exe process either using the above PS cmdlet or Hover and then navigate to the folder of the target MSIX package and execute a dir command to see the contents of the virtual folder, just as your application would “see it”, i.e. with the contents of the modification package merged inside.

Microsoft did a great job here, but there is still room for improvement. The MSIX Modification Package is an excellent opportunity for enterprises to handle the customizations of each of their MSIX packages separately.

What makes it valuable is that these customizations are now decoupled from the main application. This will save a lot of time, effort, and budget for IT professionals when packaging and deploying applications.