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?

[Liviu]

Hello Henrique,

Please accept our apologies for the delayed response. We are currently handling a high volume of support requests and are doing our best to assist everyone as quickly as possible.

To solve this problem, you will need to create your own custom action to check if a previous version is installed and set a property. Using the property, you can create a custom launch condition.

For example, you can add a PowerShell script without sequence and schedule it to run on the Init Events of the PreparePrereqDlg dialog.

Script content for verifying the encrypted upgrade code:

Code: Select all

#Requires -version 3
Param()

$upgradeCode = "CA069DE5943173841949BBF25C45270B"
$found = $false

# Remove braces and dashes, convert to uppercase (compatible way)
$code = $upgradeCode -replace '[{}-]', ''
$code = $code.ToUpper()

$paths = @(
    "HKLM:\SOFTWARE\Classes\Installer\UpgradeCodes",
    "HKLM:\SOFTWARE\WOW6432Node\Classes\Installer\UpgradeCodes"
)

foreach ($path in $paths) {
    if (Test-Path $path) {
        foreach ($item in Get-ChildItem $path) {
            if ($item.PSChildName -eq $code) {
                $found = $true
                break
            }
        }
    }
}

if ($found) {
    AI_SetMsiProperty "FOUND_UPGRADE" "1"
} else {
    AI_SetMsiProperty "FOUND_UPGRADE" "0"
}

When an MSI is installed it will store its Upgrade Code in the Windows Registry in the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UpgradeCodes\

Please note that Microsoft uses simple encryption to store upgrade codes, which means you need to do the following:

e.g. for {5ED960AC-1349-4837-9194-BB2FC55472B0}

1. Reverse first 8 characters CA069DE5
2. Reverse next 4 characters 9431
3. Reverse next 4 characters 7384
4. Reverse next 2 characters 19
5. Reverse next 2 characters 49
6. Reverse next 2 characters BB
7. Reverse next 2 characters F2
8. Reverse next 2 characters 5C
9. Reverse next 2 characters 45
10. Reverse next 2 characters 27
11. Reverse next 2 characters 0B

thus {5ED960AC-1349-4837-9194-BB2FC55472B0} becomes CA069DE5943173841949BBF25C45270B

Or, if you create a specific version registry in your setup packages, you can search for that registry to verify if an old version is already installed.

launch conditions before prereq.png (185.52 KiB) Viewed 11819 times

Attached you can find two sample projects.

Can you please test them and let me know if that helped you?

sample Prevent fresh install based on condition but allow update to proceed.zip

(9.1 KiB) Downloaded 143 times

Best regards,
Liviu

[Henrique Mesquita]

Hello Liviu,

Thank you for your response.

I've tried your approach on how to do it, but unfortunately I couldn't make to work on our side because of the structure of our actual installer project.

By now, we will have to use the approach we started: installing the prerequisites and then checking for the conditions on a .ps1 file.

In the future (near on further) we will revisit this topic on our installer when we refactor it (maybe building a new one from scratch) to try it out.

If you have any more ideas on how to counter the prerequisities installation need to only then validate the launch conditions, we'd appreciate.

[Liviu]

Hello Henrique,

You just need to run a script on the Init Events of the PreparePrereqDlg dialog. This should work.

Can you please send us your .AIP project file by email to support at advancedinstaller dot com so we can check your implementation?

Best regards,
Liviu

[Henrique Mesquita]

Hello Liviu,

Sorry for the late response, things went wild on work.

Using the approach:

You just need to run a script on the Init Events of the PreparePrereqDlg dialog. This should work.

worked, thank you!

[Liviu]

You're always welcome, Henrique!

I'm glad to hear that it worked as expected.

Let us know if there is anything else.

Best regards,
Liviu