MSP vs. MSI: Choosing the Right Patch Installer
One common question packagers often ask themself is what type of installer to use when patching an application.
Should you go with an MSI or an MSP?
In this article, I’ll walk you through both methods and help make your decision easier when you face this choice.
What Is a Patch?
In the software packaging world, a patch refers to a small installer with the scope of adjusting, fixing, or updating an existing software. This installer can come in an MSP (Microsoft Patch) or an MSI (Microsoft Software Installer) format.
The MSP is directly applied over the existing software and cannot be installed standalone.
We published more information helping you understand Windows Installer patches and also on how to create Microsoft patches.
The MSI, on the other hand, can be applied over existing software by actually uninstalling and replacing the previous version. The MSI can also be installed as a standalone piece of software and does not depend on any preinstalled software.
Now, if we consider these three definitions, the obvious answer would be to always use an MSP when you want to patch, right? Well, it’s not that simple.
Then…which to use for patches? MSI or MSP?
There is no direct answer. It all depends on the context. Here are some some questions to ask yourself before moving on:
- Do you have your own application as a software vendor and plan to release a patch?
- Are you a software packager/IT engineer and manage multiple applications that require patching?
- How big of an impact does your patch have on the main application?
- How do you distribute the application/patch?
- How big is the application for which you do the patch?
Software Vendor Here. What to Choose?
As a software vendor, you distribute your application via a website where users go and download it.
You go for MSI when:
- You want users to replace the previous version with a clean installation completely.
- Your patch includes major changes, like new features, architectural updates, or significant bug fixes.
- New users also use your software, and you want to provide a single package that works for both fresh installs and upgrades.
- Your target audience is non-technical users, and you want a simple installation process without requiring users to have a specific previous version installed.
You go for MSP when:
- Your update is a patch rather than a full version upgrade and you want to offer a faster and smaller download for your users instead of requiring them to download the entire software again.
- The software is large, and distributing a full MSI would cause unnecessary bandwidth usage for users who already have a base (non-patched) version of the app already installed.
- You want users to install the patch only if they already have a specific version of your software installed.
- The update is incremental (e.g., bug fixes, minor improvements) rather than a major version release.
- You need to preserve user settings and avoid resetting configurations, which can happen with a full MSI reinstall.
IT Pro Here Doing Patches in Enterprise Environments. What to Choose?
As an IT Pro in an enterprise environment, you distribute the patches via configuration management tools, in an automated way, and you have control over software packages in the infrastructure.
You go for MSI when:
- The main application doesn’t take up a lot of space. Distributing it will not cause any network bandwidth outage.
- You want to fully replace the previous version when patching.
- Your patch includes multiple adjustments, and it’s rather an upgrade than a small patch.
- You want to have a reliable rollback plan. MSIs have a cleaner uninstall logic than patches.
- You plan to distribute the MSI to all devices (new and old), regardless of whether they have the software that needs the patching already installed.
You go for MSP when:
- The main application has a large file size. Distributing a full version can load up the infrastructure network bandwidth and will have a longer installation time. MSP, on the other hand, will only include the changes in terms of configurations and files, resulting in a smaller installer and a faster deployment and install time.
- You have a specific group of devices that you need to patch, and the patch is a different configuration rather than a hotfix or a security upgrade
- You want to preserve the user settings on that specific application, knowing that if you do a full MSI upgrade (removing the previous version), it will also remove the settings.
Patching with Advanced Installer
With Advanced Installer, you can create patches in both MSI and MSP formats.
Thanks to its intuitive GUI and comprehensive documentation, patching and upgrading become much easier - even for beginners
For a step-by-step guide on handling upgrades and patches using Advanced Installer, check out this chapter in the Application Packaging Training Book.
You can get started with a fully functional free 30-day trial of Advanced Installer to explore its patching features, MSI/MSP generation capabilities, upgrade tools, and enterprise-level packaging options.
Conclusion
Patching is a complex and delicate aspect of software packaging that requires attention to detail and careful planning. Because patches can directly affect system stability and application behavior, it’s important to approach this process with caution to minimize risks and avoid potential issues down the line. A well-executed patch can streamline upgrades and fix bugs seamlessly, but mistakes can lead to costly problems—so make sure your choice is backed by thorough testing and a clear understanding of the impact.
FAQs
What’s the difference between an MSI and an MSP when it comes to patching?
An MSP (Microsoft Patch) is a small package designed to apply changes directly to an already installed application, while an MSI can be used either to install the software from scratch or to replace an existing version entirely. It works as a standalone installer and is better suited for major upgrades or full reinstalls.
Can I use MSPs to patch any version of my application?
No. MSP patches are version-specific, meaning they only work if the exact version they target is already installed. If you plan to mass deploy a specific patch, make sure to include the main base application in the requirement rule. Otherwise, the install will give an error and will not go through.