Jump to content

Launcher for GinENGINE games

Sign in to follow this  
LCH-711 (Bug)

Data folder removal doesn't work when uninstalling either GineverLauncher or Robbit Launcher 3 if both launchers are currently installed


If you have both GineverLauncher and Robbit Launcher 3 installed, and then you run the uninstaller for either GineverLauncher or Robbit Launcher 3 and leave the checkbox checked to remove additional data files, they are not actually removed. Unticking and reticking the box, as well as leaving it ticked, also do not work to remove those additional files. Essentially the checkbox does nothing. This basically renders the uninstaller almost completely pointless, since the additional files make up almost the entirety of the installed data.

This issue does not happen if you only have one launcher installed and you go to uninstall it.

Similarly, the issue also does not happen if you previously had two launchers installed, but you already brokenly uninstalled one of them and you are now trying to uninstall the other. Or at least it doesn't occur during the second cleanup... only the first. Meaning that if you uninstall both launchers, whichever one you uninstall last is cleaned up properly.

Current workaround: In the obscure event that you actually want to uninstall/delete the launchers and have both launchers installed, you can just manually delete anything which the uninstaller fails to uninstall after finishing the uninstallation process.

Related Issues

This issue is not related to any other issues

User Feedback

Recommended Comments

Issue Creator Current Assignee Project Manager


I did some digging today to figure out how I made this part of the uninstaller work. I was able to verify the issue more accurately and I think I finally came to an explanation.

The data folder removal is performed using a custom component called "CleanupMainApplicationFolder". This component does nothing when installed, but has an uninstall action of removing the folder pointed to by the "P.REMOVEDATAFOLDER" property. The MSI trigger performs a custom action which sets the "P.REMOVEDATAFOLDER" property to the application install path immediately before the 'validate product ID' sequence, but only if REMOVEUSERDATAONUNINSTALL is set to 1. This is the default value, therefore it IS set during install (although the "P.REMOVEDATAFOLDER" property isn't used then, so this does nothing), but during uninstall it can be toggled off by the checkbox. If you don't have the checkbox ticked, the "P.REMOVEDATAFOLDER" property is never set, so it ends up being a null pointer. This results in nothing being removed.

Thus, having the checkbox checked means REMOVEUSERDATAONUNINSTALL is set to 1, which in turn means P.REMOVEDATAFOLDER gets set to the install directory, which further in turn means that the uninstallation of the CleanupMainApplicationFolder component results in the installation directory being completely removed. Likewise if you have the checkbox unchecked, the REMOVEUSERDATAONUNINSTALL is set to 0, so P.REMOVEDATAFOLDER is never set (and thus is null), and thus the folder null is removed instead (which isn't valid, so nothing happens).

All seems OK so far, the logic makes sense, and we know this works sometimes. So we move on now and keep digging.

The component ID in the installer for the CleanupMainApplicationFolder component is set out like this:

<Component Id="CleanupMainApplicationFolder" Guid="*">

And herein lies the problem.

This instruction is supposed to auto-generate a unique component GUID. But for some reason, despite the other GUIDs in the file which are asterisked like this ending up unique, this one does not generate uniquely. Instead, the GUID of A9E06F23-F202-52C8-BBAF-DA1B58DC870E is generated for both GineverLauncher and Robbit Launcher 3 MSI files, which seems contrary to proper behaviour. (This was verified by using the WiX dark tool to decompile the MSI files currently available for download on the website.) I currently have no idea why this happened, since these GUIDs are supposed to be globally unique, so this seems like it is probably a bug or oversight in the WiX toolkit. Either that, or I misunderstood how these GUIDs are allocated. Either way, the auto-allocator is apparently unreliable.

As a result, the cleanup component of both launchers installs with the exact same GUID. Unfortunately, this breaks the uninstall behaviour.

Here are some example behaviours:

  • Install GineverLauncher.
    GineverLauncher folder is cleaned up properly. 🙂
  • Install Robbit Launcher 3.
    Robbit Launcher 3 folder is cleaned up properly. 🙂

So we can see everything works fine if you only have one launcher installed. Awesome. Now we try with two installed...

  • Install GineverLauncher.
    Install Robbit Launcher 3.
    Uninstall Robbit Launcher 3.
    Robbit Launcher 3 folder IS NOT CLEANED UP PROPERLY 😠  (and the GineverLauncher folder isn't touched either)
    Uninstall GineverLauncher.
    GineverLauncher folder is cleaned up properly. 🙂  (the Robbit Launcher 3 folder is still present)
  • Install GineverLauncher.
    Install Robbit Launcher 3.
    Uninstall GineverLauncher.
    GineverLauncher folder IS NOT CLEANED UP PROPERLY 😠  (and the Robbit Launcher 3 folder isn't touched either)
    Uninstall Robbit Launcher 3.
    Robbit Launcher 3 folder is cleaned up properly. 🙂 (the GineverLauncher folder is still present)

So it seems that whichever launcher is uninstalled last is the only one that gets cleaned up correctly, regardless of original installation order. For the one uninstalled first, the cleanup routine completely fails. So I previously thought this issue only affects the Robbit Launcher, but apparently I was wrong.

Hypothesis as to why this behaviour happens:

It seems that both program installs are adding 1 installation of the cleanup component. MSI is treating them both as the same component and tracking how many installs of the component there are. The component is only considered uninstalled when every single installation is removed. The cleanup also only happens at the point at which the package is considered uninstalled.

So on installation of the first package, some installation counter is incremented. We now have 1 copy of the cleanup package installed. Uninstalling it at this point results in no copies installed any more, so the folder is removed.

When you install a second package, the installation counter is now at 2. Therefore if you run one of the uninstallers at this point, this only decrements the counter back to 1 installation remaining, which is not enough to trigger the cleanup.

Potential fix:

I think this could easily be fixed by just manually inputting a GUID for this component for each installer, and then rebuilding the setup files. This would result in these components having completely separate GUIDs, and therefore there is no risk of clash.

Unfortunately this will not fix the issue for the small number of users who already have the launcher installed. I'm also not sure what would happen if someone were to subsequently try installing (or uninstalling) using a "fixed" installer while they have an installation from an "unfixed" version present. This will have to be tested at some point to find out.

*sighs profusely at WiX*

Share this comment

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Create a new GineverAccount today. It's easy!

Register a new account

Sign In with GineverAccount 5.1

Already have an account? Sign in here.

Sign In Now
  • Create New...