We got a question in the Advanced Installer forum about the possibility of passing arguments to a service when the parameters are received from a configuration file, such as an .INI file.

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.

One of the main things we need to consider when performing a Major Upgrade is how we will backup and restore our previous files and folders.

MSIX delivered Shared Package Containers to allow applications to share their files and registries, enabling classic Win32 apps to communicate with each other without changing any code.

If there's something we've mentioned over and over again about MSIX is that it requires digital signing. We have a diversity of resources regarding this topic, from why it is a good practice to include a timestamp when signing a package, to automating the whole digital signing process of MSIX Packages.

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

Your application's installer is the very first direct interaction of users with your product. And, a positive first impression is essential for the success of any software.

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.

Did you package Notepad++ as an MSIX, and need to add extra plugins to it?

With the experience of unfortunate security breaches in recent years, the focus of making safe and reliable applications has increased in the software industry. This is why adding a digital signature to your application has become a must -- and for MSIX applications it is mandatory.

As we've emphasized before, we're big fans of MSIX technology here at Advanced Installer. It has brought more control to developers when it comes to their packages -- as it includes options for repackaging, rolling back updates and even downgrade scenarios.

In my experience, CustomActions can be difficult to add and set up, especially in MSI, often requiring reviewing lengthy documentation or dealing with unexpected failures or bugs. If you started your career prior to the App-V and MSIX era, you have probably come across various applications installers that required reverse engineering work.

In this article, you will learn how to configure and build an Advanced Installer Visual Studio Project(AIPROJ) from an Azure DevOps pipeline.

As software packagers, we know the struggle that comes with new technologies. And there's no need to sugarcoat it -- is downright stressful.

In a previous article we had a look on how Environment Variables work with MSIX. We now know that in MSIX, Environment Variables are redefined as AppExecutionAlias.

TL;DR: Let's put it bluntly, you should never set a CustomAction to “Immediate” when you intend to change the system state.

Working with Azure DevOps pipelines can be a tedious task, especially if you have to perform updates on complex pipelines or make the necessary configurations to each of them in a short amount of time.

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.

Nowadays CI/CD(Continuous Integration and Continuous Delivery) pipeline became a best practice for developers and DevOps helping them to manage the software process in a much easier and automated way.