How does MSIX package upgrades change industry best practices?

Written by Alex Marin · July 24th, 2020

In this article, we will be exploring how MSIX package upgrades work and going through some best practices for name changing and easier upgrades.

When building a new version of an installation package, you should pay attention not only to adding improvements but also ensuring a seamless upgrade to the old version.

MSIX does not rely on product codes or upgrade codes in order to perform an upgrade of an old version. Also, if you have a look at the AppxManifest.xml, you will not find any GUID, product code, upgrade code, or any type of unique generated string.

In order to perform an upgrade, MSIX relies on Name, Publisher, Version, and Processor Architecture. This means that once you choose a name, publisher, and architecture for your package, you are basically stuck with them.

Is that a good or a bad thing? It depends on how you will use it.

For instance, here are two cases when restricting the name change is practical:

1. When vendors change the package name so often that IT Pros are unsure if they are even packaging the right application.
2. When managed infrastructures have so many different names for one single application that it makes people scratch their heads trying to identify which is what.

Keeping a consistent name for each application

To avoid the issues mentioned above, MSIX simplifies things and forces vendors and IT Pros to keep the same name for each specific application. By keeping a consistent name, it makes it easier to know which application you are dealing with and find it in an IT infrastructure.

Perhaps with this approach, we can forget the pointless rules we had to follow in managed infrastructures. For instance, having to stick to a specific form for creating names in the Add/Remove Programs entry for a packaged application, e.g.

<ProductName>-<ProductVersion>-<Publisher>-<Release>

Keep in mind that the Microsoft Store reserves the name of published applications, so if you were to change the name, that application will not be able to upgrade.

As an alternative to deal with name restrictions, you can apply Custom Powershell installations wrappers to an MSIX, but note that it is not a native way to upgrade and integrate with infrastructure management tools like SCCM or Intune.

To find out more about per-machine installations of MSIX in SCCM check out this article: https://www.advancedinstaller.com/per-machine-deployment-msix-sccm.html

Upgrade previous versions with Advanced Installer

Let's take the scenario when a sample application is already created with version 1.0.0.0, but there is no access to the Advanced Installer project, or it’s created with other tools.

There are two ways to modify and upgrade an application to a new version:

1. By using Advanced Installer MSIX Package Editor introduced with version 16.5 .
2. By creating a new MSIX project.

The first approach with the MSIX Package Editor is the easiest. If you have the source MSIX package, right-click it and choose Edit with Advanced Installer.

Once the package is opened with Advanced Installer, perform the needed changes in the package, increase the package version (in our case to 2.0.0.0), sign the package, and click Build.

Remember: Do not change the name, publisher or architecture in the process.

The second way to modify and upgrade the version of the application is when the original MSIX package is not accessible, and you need to create a new project.

To create a new package with a new ProductVersion, follow these steps:

1. Open Advanced Installer, click on New > Installer > MSIX Package.
2. In the package creation wizard, place the exact name and manufacturer as the original package and go through the process until the end.
3. Once the project is created, navigate to the Build page and select the architecture of the package - which should be the same as the original MSIX package.
4. Perform the needed changes in the package, sign it, and click Build.

In both cases, after the package is built, when an installation is attempted the Install button is replaced with Update

Conclusion

The new industry trend brought by MSIX is to give little room to name alterations during the upgrade process of an installation package. As I mentioned, this is to reduce bad practices and confusion related to the package upgrading process and to provide the market with a uniform way of working.

Did you have any challenges with name changing while upgrading an application? What do you think about the new best practices for upgrading? Tell us in the comments below.