First published on MSDN on Oct 26, 2018
In a previous post
we have learned how, thanks to the MSIX packaging format and modification packages, IT Pros can break the packaging paralysis that affects most of the enterprise environments.
Thanks to this approach you can decouple the main application from the customization (branding, configuration files, etc.) that the IT Pro department have to make it compliant with the business requirements. This way, whenever the developer releases a new version of the application, the IT Pro department doesn't have anymore to repackage the new version from scratch in order to embed the customization, but they can just deploy the update. Since the customization are now stored inside a modification package, which is independent, they will continue to work just fine.
Caphyon has just released a new version of Advanced Installer, 15.4, which greatly improves the experience of building modification packages.
Let's see how it works.
Building a modification package
Once you start Advanced Installer, you have a new template called
which you can find in the
The template allows you to manually input all the information about the package, including the identity of the target application you want to modify. However, Advanced Installer is able to simplify the experience by allowing you to directly pick the MSIX package of the application you want to customize.
Just press the button near the
field under the
Target Package Dependency
section and choose the MSIX package. The tool will grab all the information and associate the right ID, Publisher Id, etc.
All these values will be automatically translated into the right info inside the manifest, under the
<uap4:MainPackageDependency Name="AdventureWorks.MyEmployees" Publisher="CN=Test01D44CEED709FB30"/>
supports two attributes:
is required and it's the identity of the MSIX package you want to modify
is optional and it's required in case the publisher of the original MSIX package is different than the publisher of the modification package you're building
However, as you have noticed, we didn't have to input these information manually, but they have been automatically extracted from the MSIX of the main application.
Choosing the main MSIX package you want to modify, instead of manually setting all the info, has also another advantage: it will provide you a much better user experience, thanks to a new feature added in the Advanced Installer 15.4.
Define the content of the modification package
Before talking about this new feature, let's understand the background of the packaged application I'm trying to modify.
I'm using a simple Windows Forms application which displays a list of employees inside the main window:
The application leverages two configuration files, which are both stored inside the
C:\Program Files (x86)\MyEmployees
One it's called
and it contains some parameters that can be customized by the IT Pro department, like the branding you see in the About page.
One it's called
and, instead, it contains some default settings that can't be customized.
Due to this configuration, the main application only ships with the
file, which is deployed in the
C:\Program Files (x86)\MyEmployees
folder during the installation. The
file can be added, at a later stage, by the IT Pro department to customize the application. This is how this configuration looks like in Advanced Installer:
When I generate a MSIX package out from this definition, what you get is a package which contains a VFS folder with the subpath
If you have some experience with the Desktop Bridge, you should be familiar with the Virtual File System concept; otherwise you can review
the official documentation
Long story short: the Virtual File System mimics the real system folders. When the application tries to read the
file from the
C:\Program Files (X86)\MyEmployees
folder, Windows will first redirect the call to the special VFS folder inside the package.
Now that you have understood the background of the main application, let's see what happens in Advanced Installer when you create a modification package and you choose its MSIX as a target package.
Move to the
Files and folders
section, which is the one where you can add the content you want to include in the modification package.
Do you see what's happening? Advanced Installer, other than grabbing the MSIX identity, is also retrieving the list of files which compose the main package. As such, we can see that the application contains inside the path
Program Files (x86)\MyEmployees
file, which is coming from the target package.
Now let's add our
file inside the same folder. Right click on it, choose
and look for the file on your computer.
As you can see, we can clearly understand which files are coming from the target package and which ones, instead, are part of the modification package.
This view is really helpful to really understand how modification packages work. For the main application, in fact, the modification package is completely transparent: it doesn't matter if the JSON files are included in the VFS folder of the main package or in the VFS folder of the modification package. The application will be able to read them without having to make any change in the source code, like if both files are in the real
C:\Program Files (x86)\MyEmloyees
Neat, isn't it?
The same concept applies to the registry. If you move to the
section of the tool, you'll be able to quickly see which keys are created by the main MSIX package and which ones, instead, are customized by the modification package.
In this post we have seen how Advanced Installer can make your life much easier when you have to create a modification package for an existing MSIX. Specifically, version 15.4 has greatly improved the user experience, by allowing to see in the same interface which files are part of the original MSIX package and which ones, instead, will be added by the modification package.