Henrique Mesquita
Posts: 25
Joined: Thu Apr 27, 2023 12:22 pm

How to ensure a new project assumes the Upgrade identity of a legacy installer and removes all its resources

Hello,

This will be a big post, I will divide into topics to make things clear.

We are creating a new installer project that must act as the official replacement for an older, existing product.

We need the new installer to seamlessly take over, but I'm facing challenges with leftover resources and the "A newer version is already installed" error during tests.

I have tested some approaches I have found here on the forum and on searches but none have worked completely.

What will change
  • We will install a new program;
  • We will create a new installer.
The new installer must be seamlessly upgradable from any previous version of our old installer.

What we have today
Our installer (EXE Bootstrapper) consists of:
(they are installed in that order)
  • 1. .NET Runtimes
  • 2. Main app (Windows Service)
  • 3. Several sub-apps (Windows Services) added as Feature-based Prerequisites (each has its own AI-generated MSI);
The folder tree looks like this:

Code: Select all

C:
└── full path
    └── RootFolder
        ├── MainApp
        ├── Prerequisite 1
        ├── ...
        └── Prerequisite N
What we want to build
A new installer, that installs a very simple Windows service built using the "deamon" concept (reduced to the minimum necessary). Everything else will be deployed via zip (including) our main app, and they will run as processes.

Our main questions
  • 1. How to ensure the new installer is recognized as the "Successor" (v2.0) of the legacy one? We are using the same Upgrade Code, a new Product Code, and a higher Product Version;
    • We have tried the Upgrades > Upgrades > UpgradeCode > Remove for both, main and prerequisites. Their files are deleted, but registry keys and other Windows Installer (I think) related files/data still remain, causing the "A newer version is already installed" error.
  • 2. Since the new version changes from MSIs to ZIP-based deployment, how can we force the removal of all legacy components that were originally registered as separate features/prerequisites?
  • 3. If there isn't a pre made option to do that, what is the best approach we can take to make sure that our new app is installed and everything that was installed by our old installed are removed?
We feel a bit lost regarding the proper "cleanup" sequence in Advanced Installer for this transition.

Thanks in advance!

Edit
We are also thinking about keeping the existing installer, with our new zip-based deployment.
Since we will be removing our feature-based prerequisites, how can we ensure that their leftovers (Windows Services, registry keys, files and folders) are deleted correctly?
Catalin
Posts: 7717
Joined: Wed Jun 13, 2018 7:49 am

Re: How to ensure a new project assumes the Upgrade identity of a legacy installer and removes all its resources

Hello Henrique,
1. How to ensure the new installer is recognized as the "Successor" (v2.0) of the legacy one? We are using the same Upgrade Code, a new Product Code, and a higher Product Version;
We have tried the Upgrades > Upgrades > UpgradeCode > Remove for both, main and prerequisites. Their files are deleted, but registry keys and other Windows Installer (I think) related files/data still remain, causing the "A newer version is already installed" error.
2. Since the new version changes from MSIs to ZIP-based deployment, how can we force the removal of all legacy components that were originally registered as separate features/prerequisites?
3. If there isn't a pre made option to do that, what is the best approach we can take to make sure that our new app is installed and everything that was installed by our old installed are removed?
All these three points should be covered by the major upgrade mechanism.

Most likely, they are not because we have the problem you mentioned at the start of the thread.

Here is an article that explains why that error might appear and how to fix it:


A more recent version of X is already installed on this computer - corner case scenario and how to avoid it

Basically, we need to make sure that we only use the first 3 fields of the ProductVersion property.
Screenshot_122.png
Screenshot_122.png (1002 Bytes) Viewed 16179 times

Could you please check that and let me know if that is your case?

If the upgrade works as expected, then 2nd and 3rd points should be taken care of automatically.

Best regards,
Catalin
Catalin Gheorghe - Advanced Installer Team
Follow us: Twitter - Facebook - YouTube

Return to “Building Installers”