Multiple Apps Using the Updater — Uninstalling One Breaks the Rest

[leeroy]

We maintain several desktop applications that all share the same Advanced Installer "updater.exe". We’ve run into two major issues:
1. Cross‐app contamination

• When we uninstall App A, the shared updater it would seem doesn't service the other applications, and subsequently App B (and any other app) can no longer apply updates.

2. Orphaned files and shortcuts

• Uninstalling one app often leaves behind files (including shortcuts) that belong to that installation.

Our Questions
1. Can each application ship with its own dedicated updater?

• If so, is it sufficient to give each app’s update entry a unique "file name" and/or "description" via CLI?

2. How do we automate that naming through the CLI so that—for example:

• App A’s updater is AppA-Updater.exe / description "App A Updater"

• App B’s updater is AppB-Updater.exe / description "App B Updater"
  
  Ideally, we could script something like:
  

  Code: Select all

  AdvancedInstaller.com /edit MyAppConfig.aip  /SetUpdaterFileName "AppA-Updater.exe"
  AdvancedInstaller.com /edit MyAppConfig.aip  /SetUpdaterdescription "App A Updater"
  

  and have each MSI bundle its own uniquely named updater so that uninstalling one does not affect the others.

Any guidance on recommended best practices for per‑app updater isolation, and on the exact CLI switches or project settings to use, would be greatly appreciated!

[leeroy]

I see there is a service section we can manipulate and name to create a unique service tailored to our needs.

[leeroy]

Unfortunately even though we now have unique service names per product install, only the first installed updater service is uninstalled when the applications are removed leaving orphaned services behind.

[leeroy]

This unfortunately gets worse. Senario:

1. Install:

• App A

• App B

2. Uninstall:

• App B

3. Outcome:

• App B Orphaned Service remains

4. Install:

• App B

5. Uninstall:

• App B

6. Outcome:

• App B Orphaned Service remains

7. Uninstall:

• App A

8. Outcome:

• App A service removed properly

• App B Orphaned Service remains

10. Install:

• App B

11. Uninstall:

• App B

12. Final Outcome:

• App B service removed properly

This indicates an issue where the updater service installed by App B becomes orphaned and is only cleaned up after App A is fully removed and App B is subsequently reinstalled and removed again.

[Catalin]

Hello Lee,

Do your applications share one single updater.exe?

If that is the case, we are talking about "shared components" here.

A shared component is a component that in the registry has a counter for each application that installs it. The component is then removed when that counter reaches 0, otherwise it stays "orphaned" like you mentioned.

If, when you uninstall App B, you check the uninstall log, do you see something along the following lines:

Code: Select all

Disallowing uninstall of component...

If so, here's an FAQ that explains that into a bit more detail:

Why files are left behind after package uninstall?

Best regards,
Catalin

[leeroy]

Hi Catalin,

Each application includes its own distinct updater—for example, App A Updater (AppAUpdater) and App B Updater (AppBUpdater)—and both appear as separate services when installed. However, only the updater service for the first installed application is ever removed, even if both applications are later uninstalled. The second updater service remains orphaned.

Each application also has a unique Product Code and Upgrade Code, so there’s no overlap in identifiers between them.

I’ll review the uninstall logs and see if we can find any "Disallowing uninstall of component" entries.

Best regards,
Lee

[leeroy]

Hi Catalin,

We did find several instances where `Disallowing uninstallation of component` was logged. It appears that some components within the main feature were sharing the same ComponentId (GUID). However, after eliminating these duplicate GUIDs and observing we no longer see that message, `Disallowing uninstallation of component,` the issue still persisted with no change in behavior.

Best regards,
Lee

[Catalin]

Hello Lee,

Thank you for your followup on this!

If possible, could you please share with me the following resources:

- a copy of the AIP file used to build InstallerA

- a copy of the AIP file used to build InstallerB

- a download link for InstallerA

- a download link for InstallerB

by email at support at advancedinstaller dot com so I can run some tests and further investigate this behavior?

Best regards,
Catalin

[leeroy]

Hi Catalin,

Based on your earlier suggestions, we investigated potential GUID collisions and found one related to the upgrader component. Although it didn’t log any Disallowing uninstallation of component messages, updating this component with a unique GUID resolved the issue. More importantly, we came across this article in the user guide, which describes exactly what we were experiencing. We’ve now made the necessary adjustments to eliminate any remaining component GUID collisions.

Thank you again for all the help!

Best regards,
Lee

[Catalin]

Hey Lee,

Awesome, I'm glad to hear everything is working as expected now!

I'm also glad the article I wrote helped you.

Best regards,
Catalin