Prevent fresh install based on condition, but allow update to proceed

[Henrique Mesquita]

Hello everyone,
I hope you're all doing well.

So, we have an installer built with Advanced Installer. The installer consists of:

1. Main application;
2. Two .NET runtimes;
3. Nine Feature-based secondary applications (Nine full installers built with Advanced Installer as well).

Some important additional information about our .aip project

We're currently using Advanced Installer version 20.7.1 and are unable to upgrade at the moment.
We are using this option: Prerequisites > Global Prerequisites Options > Check launch conditions before searching for prerequisites so that the launch conditions are before installing the .NET prerequisites.
Our installer has multi-language support.

Now, we want to change the installation process:

New installation rules

The installer must block fresh installations (i.e., when no previous version is installed on the computer) if:

• An specific X software is found, and its version is below N.

The installation must proceed if:

• That specific X software is not installed, or;

• If the version is not found, or;

• Its version is above N.

The update must proceed anyway:

• The update must always proceed, regardless of whether the specific X software is installed or its version.

What I have tested so far

The approach we used to determine if the software is installed is:

1. A search to retrieve a raw value of the registry from key: HKEY_LOCAL_MACHINE\SOFTWARE\My Company\Team\Product\Version. The value is taken from 'Version';
2. A launch condition to verify if the value is below N.

On Launch Conditions, we tried those custom conditions:

NOT OTHER_SOFTWARE_VERSION OR OTHER_SOFTWARE_VERSION > "x.x.x" OR OLDPRODUCTS
NOT OLDPRODUCTS AND (NOT OTHER_SOFTWARE_VERSION OR OTHER_SOFTWARE_VERSION > "x.x.x")
NOT Installed AND (NOT OTHER_SOFTWARE_VERSION OR OTHER_SOFTWARE_VERSION > "x.x.x")

Both approaches work well and block a new installation when Y version is below N, when Y version is above N or when Y is not present, but when we update the application (silently), the launch condition is triggered, when we wanted to not be triggered, blocking the silently update and killing our service.

Looking for a solution

In my searches, I found some users saying that sometimes, some properties (like Installing, OLDPRODUCTS and etc.) aren't populated in time. I have tested myself and displayed Installed, OLDPRODUCTS and UPGRADINGPRODUCTCODE (this one just to check the test) on the installation logs and all of them were empty. This may cause the condition to be triggered on the update or are we misunderstanding the process?

With that, I ask you: is that the best approach for this situation?
If yes: how can we make it so that it ignore that custom condition when the software is updating itself silently?
If not: which approach should we take?

Thank you for now, any more information you need, just ask and we will provide as soon as possible.

Edit: We also tried a Custom Action approach, but we couldn't get it to work.

[Catalin]

Hello Henrique,

In my searches, I found some users saying that sometimes, some properties (like Installing, OLDPRODUCTS and etc.) aren't populated in time. I have tested myself and displayed Installed, OLDPRODUCTS and UPGRADINGPRODUCTCODE (this one just to check the test) on the installation logs and all of them were empty. This may cause the condition to be triggered on the update or are we misunderstanding the process?

This might indeed be the case. These properties, if I remember correctly, are populated during the "FindRelatedProducts" standard action.

In your case, the Launch Conditions are launched after that.

What I would suggest is sort of delaying this check.

We can do that by giving up the Launch Condition approach and having a Custom Action check for what we need. For example, we can use a script to check that and schedule the script after the "FindRelatedProducts" so we can also make use of OLDPRODUCTS property.

From that same script, we can spawn a messagebox if needed, just like for launch conditions and after that, we can exit the installation by returning 3 to the main installer. For example, in PowerShell we can use "Exit 3".

Hope this helps!

Best regards,
Catalin

[Henrique Mesquita]

Hello Henrique,

In my searches, I found some users saying that sometimes, some properties (like Installing, OLDPRODUCTS and etc.) aren't populated in time. I have tested myself and displayed Installed, OLDPRODUCTS and UPGRADINGPRODUCTCODE (this one just to check the test) on the installation logs and all of them were empty. This may cause the condition to be triggered on the update or are we misunderstanding the process?

This might indeed be the case. These properties, if I remember correctly, are populated during the "FindRelatedProducts" standard action.

In your case, the Launch Conditions are launched after that.

What I would suggest is sort of delaying this check.

We can do that by giving up the Launch Condition approach and having a Custom Action check for what we need. For example, we can use a script to check that and schedule the script after the "FindRelatedProducts" so we can also make use of OLDPRODUCTS property.

From that same script, we can spawn a messagebox if needed, just like for launch conditions and after that, we can exit the installation by returning 3 to the main installer. For example, in PowerShell we can use "Exit 3".

Hope this helps!

Best regards,
Catalin

Hello Catalin,

Thank you for the quick response!

Ok, I have tested the approach you suggested, but there's an issue with our installer:

It consists of two steps:

1. Prerequisites installation dialogs (if missing), with language selection, which open and close automatically as the starting dialogs; then,
2. Main application installation with a silent, feature-based install process.

If I delay the check until after the FindRelatedProducts step, we encounter a strange behavior (from a UX perspective):

The installer opens, checks for missing prerequisites, installs them, closes the first part, and then opens the second part (main application);
Now, it knows it can't be installed because of our rule.

I hope I explained the scenario in an understandable way.

Is there a way to cancel the installation process from (or before) the prerequisities step?