In our previous article titled "How to automate the MSI building using GitHub Actions", we saw how you can use Advanced Installer's own GitHub Action to automate the build of your MSI packages.

In this article, we will take a look at how MSIX technology handles log files whenever an installation issue occurs.

What's the most efficient way to perform quick edits to an MSI package?

In 2018, MSIX was announced by Microsoft as the new universal package format for Windows 10 apps with the later support on desktop, mobile, and other Windows 10 devices.

We've received inquiries from users that encounter issues with the SCCM cache folder.

We are so proud to announce Alex Marin’s brand new work: the MSI Packaging ebook - visit the link to get your free copy.

Sometimes we need to perform quick edits to our MSI packages without having to create a new project or going through the whole repackaging process.

Sometimes we need to have a single distribution package as an MSIX, which includes MSIX supported features along with MSI features that are no longer available (such as old drivers).

There are scenarios where you need to change a file version programmatically with each launch. To achieve that, we will set an installer property that changes with each release and then uses its value within your installer.

In order to allow a program to execute, you must first register its extension as a DLL or OCX.

One of the most asked questions in the industry is related to CAB files and what embedding options these have within the WiX Toolset.

The method to replace an existing configuration file varies depending on the application installer's format. For example, whether it's a vendor MSI from an Independent Software Vendor (ISV) or an EXE.

Self-healing, also known as self-repair, is one of the major benefits of the Windows Installer technology. In simple words, it ensures packages are secure and resilient by automatically checking and fixing them.

Many applications keep settings or configurations in files that later get stored in per-user based locations, such as %appdata% or %localappdata% folders.

In this article, we will explore what happens during a Windows Installer registration and what are the repercussions that appear if you don't register your MSI during installation.

Applications often require different types of permissions to operate smoothly - so adding permissions to files, folders, and registry keys is a standard practice in MSI.

Ever wonder how an MSI registration ProductID is created?When installing an MSI, it registers on the system with a "strange" ProductID (different from regular ProductIDs) which is sometimes tricky to find. This is particularly challenging when you're trying to locate the package installer by its ProductID.

Scripts have been traditionally used by ISVs to add Custom Actions to their applications and make changes to the environment. They have been present in MSI and App-V packaging formats for ages, while for MSIX, they were introduced and supported about a year after Microsoft announced the MSIX release.

MSIX packages are installed by default per-user, and the option to provision per-machine MSIX applications is possible through SCCM - which is not yet available in Task Sequences.

With App-V packages closing to end-of-life (2026), the reality of a transition to MSIX is much closer and many are starting to research the ins and outs of what it entails. Although we now know that MSIX is not an update to MSI, but a completely new technology, there are still some correlations that we'd like to address.