You are invited to join the upcoming webinar "The most common packaging mistakes that developers make. And how to avoid them." where Bogdan Mitrache, Product Manager Advanced Installer, will show us how to create professional installation packages and deliver a customer-winning experience.

While for MSIs, this was an optional step, signing your MSIX package is mandatory. Microsoft’s MSIX technology requires the use of code signing certificates to deploy packages.

This month we are extending our virtualization management support with our new Docker integration.

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.

Announced in 2018, MSIX was presented by Microsoft as the universal package format. Although it may not be widely known, the MSIX technology retains the functionalities for translations and localizations of Universal Windows Platform or UWP Apps.

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

Over the years, we've received many questions regarding how Custom Actions work with PowerShell scripts in MSI.

We have always been committed to empowering our users with an efficient and secure packaging tool. Starting with Advanced Installer 18.3, we are moving ahead with the Visual Studio Extension to support .Net Core projects (including the .NET 5 version).

Many of us are aware of the importance of securing our applications and how digital signatures are a solid way to avoid security breaches. For those looking into MSIX, you must know that Microsoft enforces digital signature for all packages within this technology. There is no exception.

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.

A while ago we released a free tool for APP-V called TweakAPPV at Advanced Installer. Our purpose with this tool was to take App-V 5.x editing from the command-line to a new level by offering full access to the package contents.

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.

At Advanced Installer our focus was always to simplify packaging tasks and streamline repetitive scenarios.

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.

“Your package is not digitally signed”.. “The certificate is not installed on your machine”.. “A new package is already installed..”

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

We all know that MSIX is an evolving technology - but it is not a fix-all for all the situations we encounter when running Windows applications.

Advanced Installer 18.1 is another step forward towards more automation, and less manual packaging.

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.