Logic when running Setup and app is already installed

[caesay]

Current logic if running Setup after app already installed is to just eradicate app data and try to re-install.

This can cause data loss if user settings are being stored, or could even leave the app broken if there are locked files and Squirrel leaves the directory partially deleted.

We could improve this by:

• Trying to rename the directory before deleting
• Give the user a popup dialog and ask if they would like to "Repair" or "Start" the app. Repair can use the old logic, "Start" can just run the SquirrelAwareApp and exit.

Related to

• Check and Repair a version directory #55
• Initial Install event is not sent until AFTER attempt to delete RootAppDirectory Squirrel/Squirrel.Windows#498

Also, the issue of "starting Setup.exe multiple times" also can cause a problem (Squirrel#1717). There is a global "lock" (filesystem based) in UpdateManager, but we need some method of synchronisation earlier on (before Setup.exe starts extracting things, and before Update.exe tries to delete things)

Edit 12/05/2022

Before deleting directories (like the app data root) we now try a rename first, so we will not leave a directory partially deleted.

We still need to:

• Deprecate the "filesystem lock" for a system mutex which is shared by UpdateManager and Update.exe.
• Add "Repair" function to UpdateManager (which re-extracts the latest local nupkg)
• Add "Repair" command to Update.exe CLI and Uninstall registry

None of these items are relevant for MacOS.

[caesay]

Working on this as an idea for the Windows Setup.

[KennyTK]

I dislike "Try Elsewhere"

• Applications may expect directory of %LocalAppData%\MyApp so giving users option to change hinders developer control.
• Multiple versions of application could be installed concurrently.

Burning the entire directory (and user config inside) on install, overwrite, and other installer behavior decisions would be better left to developer than user in my opinion.

[peppy]

For our use case, we'd also hope the user can only install to one location. Running a second time should repair (overwrite). At most I'd expect a popup to be something like "You already have the application installed. Would you like to repair the installation? Y/N".

[caesay]

One thing I am considering is that the app installed where you want to install might not be the same app. So the "This application is already installed, would you like to repair?" might not be entirely accurate. Imagine two apps with the same Id from different publishers.

We could minimize this risk by installing apps to %localappdata%/publisher/{id} or even %localappdata%/Clowd.Squirrel/{id}. Or we could try to detect if it's the same app or not via setup, and provide the "repair" prompt if it is the same app, and a "can't install" prompt if not. But this complicates the setup code further, and may not even be accurate. If an important file got deleted, it might prompt the user to try to re-install, which then could fail if we were looking for that file and can't find it so think it's not the same app.

On the point about "up to the developer, not the user" - this itself is a very contentious issue. Many people want to ship applications where install location is up to the user, and I get asked about adding this functionality regularly. Many users expect this option too, although perhaps less in the last few years.

[caesay]

I'm thinking this is what I'll go with for now.

In the future, it might be a good idea to ship a choice of different installers. This "quick" installer can remain how it is. When building Squirrel packages, the developer could have the choice between this "quick" installer, or the "configurable" installer, which allows the user to decide where to install the application.

[caesay]

Added in v4

[Noah1989]

Where is the v4 branch? Or did you mean v3/develop?

[caesay]

Hi @Noah1989,

V4 is going to be released here https://github.com/velopack/velopack. Although this started out as a fork, there is very little of the original code left now, and a lot of things have changed. Right now, I'm just writing migration tests to make sure that Squirrel.Windows and Clowd.Squirrel can migrate seamlessly to Velopack, and then I'm going write documentation, release the official packages and announce the move. Should be in the next week or so!