Every software packaging department has its own rules when it comes to MSI - whether we talk about naming convention (package naming, product naming) or package description and comments.

Lessons I have learned from making many mistakes in my enterprise software packaging newbie (and not only) years.

In our previous MSIX related blog articles, we’ve approached some of the MSIX particularities and different scenarios such as Digital Signing, MSIX Deployment via SCCM, MS-AppInstaller Web Protocol, and Context Menu.

For those new to Windows deployment/management, Windows Installer is Microsoft's solution used for the installation, removal, but also maintenance of software. Windows Installer was released for the first time when Windows 95 came in and has been developed over time since then.

If you are in the software packaging business, you might have heard of WIX bootstrapper. This was released by Microsoft back in 2004, and it was the first ever open source license project for them.

Sometimes you might end up in a situation when you cannot uninstall a package. We already covered how you can recache an MSI in our user guide. However, we noticed that this might not work for transforms (MSTs) and a different solution is needed.

Let’s assume that you have an application that installs files or registry in a user location. In this article we explain how you can install that information for all users by using MSI, APP-V or the new Microsoft installer technology, MSIX, a short cleanup process description, and a short comparison between them.

In the lifecycle of an application package, it comes a point when an update is required. Whether we want to fix minor bugs and vulnerabilities, or we come up with some improvements and big changes to our app, we must deliver it as an update.

Self-repair is one of the most powerful functionalities Windows Installer offers. It gives the ability to check and fix broken packages automatically, saving you valuable development time.