MSI Upgrade vs. MSP Patch. Which one to use?

What is a patch and how does it work with MSP?

A patch is an incremental update to an existing installation of your application. However, you cannot install an MSP if the target version (the one you want to update) is missing.

One of the main benefits of using patches is that they carry a low amount of data, including only the updated files, scripts, and registry. Unlike an MSI, which contains all the data.

The low data transfer characteristic of the MSP is especially convenient when deploying a patch over a high-latency network or via Azure, as there may be additional costs associated with data transfer between Availability Zones. In situations like these, patches are ideal for making minor fixes.

What are the most common restrictions for patches?

When dealing with patches, be aware of the various restrictions that come with them. Not taking them into account could result in breaking the functionality of your main application or causing the patch installation to fail.

Now, we'll discuss the most common restrictions that you should pay attention to when working with patches. By understanding these limitations, you can make sure that your patching process goes smoothly and doesn't cause any unexpected issues.

The most common restrictions for patches are:

• Do not change the primary keys in the File table between the original and new MSI file versions.
• Do not move files from one folder to another.
• Do not move files from one cabinet to another.
• Do not change the order of files in a cabinet.
• Do not change the Component GUID for any Component.
• Do not change the name of the Component's key file because this would require changing the Component GUID.
• Do not reorganize the existing hierarchy of Features and Components. A new Feature can be added, but if a parent Feature is removed, all its child Features must be also removed.
• Do not remove Components from a Feature.
• The Target and Upgraded MSI packages must have the same name.
• The Target and Upgraded MSI packages must have the same Product Code.

You can find the full list of restrictions for patches on the Microsoft website.

Patching can be very complicated and difficult to work with, therefore make sure to properly follow the MSI/MSI best practices.

How to create an MSP in Advanced Installer?

If you're new to patching, you may notice that creating an MSP is not quite an easy task. Unlike MSIs, where you can create them with a click of a button, MSPs require additional steps and can seem more complex. But don't worry!Here are the clear steps to create an MSP in Advanced Installer:

1. Create the MSI for v1.0 of your app.

2. Create the MSI for v1.1 following the patch rules.

3. Create a patch project to compare the two MSI packages.

You can find a more in-depth explanation of how to create an MSP in this article: What are .MSP files, how to create and extract them?

How do patches work with MSI?

When it comes to MSI patching, it involves uninstalling the older version and installing the current one. Although it can be applied to both computers with and without the older version, its downside is the large size of the complete installation package.

Unlike MSPs, upgrading with MSIs has fewer restrictions since you are basically uninstalling the old version and installing the new one. In this case, you simply need to use the Upgrade functionality and add the upgrade code of the previous version of the MSI.

Another method is to use a custom action like we shared with you in our article: Uninstall another MSI when my product is uninstalled. In that case, the custom action will not prompt the user, instead it will still be executed after "Install Execution Stage" -> "Finish Execution" -> "InstallFinalize".

MSI upgrading also allows you to redesign the package without affecting the original one, giving you the flexibility to modify installation sequences, custom actions, and more.

What are some downsides of MSI packaging?

There are very few reasons you wouldn’t choose the MSI upgrade versus the MSP patch.

Some of them are related to the size of the package. Unlike MSPs, an MSI contains all the data, and it will have a higher impact over your network when distributing the package in a managed infrastructure. In some cases, which may result in additional costs.

Conclusion

It is common for ISVs and IT Pros to choose the MSI upgrade path instead of patching with MSP, since MSI upgrades offer flexibility and the ability to redesign the whole MSI without impacting the original package.

On the other hand, we see the example of Adobe, which is widely known for the patches they have developed over the years. MSP patches have a lower impact on the network and they are very convenient when it comes to small fixes.

Regardless of which option you choose, Advanced Installer offers comprehensive features and guidance to help you create effective and reliable patching solutions for your software.

So, if you have a deeper knowledge of the Windows Installer database, you can also create great patches.

It’s all up to you to decide which path you go, but for non-experienced ISVs/IT Pros, the recommended way would be MSI upgrades.

Learn more about MSI Upgrades and Patches in our MSI Packaging Training series: