Revenera logo
Image: MSIX Values – Modification Packages


In my previous blog, I talked about Package Support Framework and how MSIX solves the problem of running traditional Win32 apps by a community driven route. Now I would like to focus on another important piece of MSIX—Modification Packages and why they are important if you are an ISV developing software or an IT Pro, or as a software consumer.


Before I jump into what a modification package is, let’s start with, “Why?” If you are an IT Pro, you would have repackaged hundreds of packages. While repackaging a vendor setup is one side of the story, adding your enterprise’s customizations is a totally different story. It could be a simple enterprise branding or a complex feature customization. IT Pros have been managing this for ages now without actual access to the source code. When you have your customizations for a given vendor app ready, you definitely don’t want to do this over again when a new version of the vendor app is available. So, there is a pressing need for isolating customizations from the core app. Traditionally, transform files (.MST) are most likely how you applied customizations to your setups. The question is, if MSIX is the next standard, how do you do the same without access to source?

While customizations are for IT Pros, from an ISV point of view, there is an increase in developing modular applications where the base app is kept separate from any plugins. Imagine you are developing an editor app and over a period of time you want to add PDF editing capabilities. Best practices suggest to keep the base and plugins separate.

Enter Modification Packages!

Modification Packages

Modification packages help you apply customizations on a given base app or add plugins/addons without changes to the base app.

With this approach, your base app and customizations/plugins are in separate MSIX packages giving you the isolation you require and removing the need to create your customizations again. As of this blog post, MSIX supports modifying the files and registry entries in the base app.

To put it simply, if your base app has, say ‘settings.xml’, you can have a modified version of settings.xml in the modification package to tweak the app settings in your enterprise. MSIX runtime will honor the settings.xml from the modification package instead of the base package allowing your customization to take effect.

Installing and Uninstalling Modification Packages

Modification packages are always bound to a base app. In fact, both of them share the same identity. This is what helps MSIX runtime to pick the customizations. They can’t be installed standalone. So, while creating a modification package, you need to mention the base app in your manifest file in the Dependencies section.

Before installing the modification package, the base app should be installed. Else, you will be presented with an error.

You can find all the modification packages to your base app from Apps and Features (Windows Settings –> Apps & Features). Select your app and navigate to ‘App add-ons & downloadable content’ to find them.

You will be able to uninstall them without affecting the base app.

InstallShield icon


Create native MSIX packages, build clean installs, and build installations in the cloud with InstallShield from Revenera.

Below is a short demo on how to create Modification Packages using InstallShield.


Stay tuned for more MSIX goodness. As usual, share your thoughts in our community or comments below.

Additional Resources

MSIX Values – Basics of MSIX

Supporting a modular Windows application with MSIX and Optional Packages