Use a 'current' directory instead of 'app-{version}' for the latest app version

[caesay]

Problem

Currently an application will be running from a directory like app-1.0.1. The application binaries moving around in each version has several disadvantages:

• Application shortcuts (particularly taskbar-pinned ones) need to be continually updated
• File associations / url protocol mappings get broken on updates (as they need to point to an absolute exe location)
• Tray icons can not be pinned. There was an attempt to implement a fix for this in the original Squirrel by modifying a binary registry entry, but this does not work because Explorer keeps the pinned icons in memory and overwrites this value when it exits.
• Firewall rules will be lost on updates

A workaround for taskbar-pinned shortcuts exists, and StubExecutable's were created in an attempt to fix some of the other issues, but from the above, it only helps with shortcuts and associations/protocols that require a static exe location.

Tray icons and firewall rules are based on the currently executing process path - so these things remain broken.

Additionally, StubExecutable's create additional issues

• They are marked as WINDOWS_GUI_SUBSYSTEM, meaning they do not attach a console, and will fail to run a console app properly. (this could be fixed by patching stub's with the same subsystem as their target exe, but it is a significant unnecessary effort)
• They are C++ and windows-specific, meaning for Cross-platform package building and deployment #17 they will either need to be removed, or a cross-platform implementation would need to be created.

Proposal

• Squirrel extracts MyApp.nuspec into each app directory. This file can be parsed to determine the current version, and other metadata (like release notes), instead of relying on the folder name.
• We create and maintain a 'current' junction, which always points to the latest app directory.
• Stub's are removed, and shortcuts etc always point to %localappdata%\MyApp\current\MyApp.exe
• We add hooks at various startup points, such as during Update.exe:ProcessStart, UpdateManager.RestartApp which will update the current junction to point to the latest app version.

Even though the real binary location will still change in each version, as long as it's always executed via the junction, windows will see the binary path as %localappdata%\MyApp\current\MyApp.exe and all the aforementioned issues should work. This needs to be tested with firewall rules and tray icons beforehand.

Side note: If we are extracting the nuspec to each app dir and using it for metadata storage, perhaps we could automatically add a <squirrelFramework>...</> tag when creating releases, and verify that the required dependencies are installed before updating the junction (eg. for #9)

[theresia-tobii]

When you fix this, is it possible to make it work when updating from a previous version where the latest is not in a current directory?

[caesay]

While I am breaking a lot of things about how Squirrel.Windows works, I strive to make all of my changes backwards compatible for installed apps. It should always be possible to upgrade from any recent-ish version of Squirrel.Windows, or any version of Clowd.Squirrel to the latest version of Clowd.Squirrel. This is also the reason that the command line interface for Update.exe is largely the same, to make migrations easier.

[felipeleon73]

• Application shortcuts (particularly taskbar-pinned ones) need to be continually updated
  ...
  A workaround for taskbar-pinned shortcuts exists, and StubExecutable's were created in an attempt to fix some of the other issues, but from the above, it only helps with shortcuts and associations/protocols that require a static exe location.

Hi caesay,
Could you tell me what this workaround is?

[caesay]

Regular shortcuts (created by Squirrel) now point to the stub executable, and do not need to be updated. Pinned shortcuts still point to the actual application exe in the version directory, so they need to be fixed during every update.

There is a routine in Squirrel (same in this fork and the original) which scans the pinned shortcuts and attempts to fix the shortcut target during updates. That code is here.

[caesay]

This has been completed in develop branch, it will be released in the 3.0.0 previews soon.

[hutterm]

@caesay is there an ETA when this will be released?

[caesay]

@hutterm This is implemented in 3.0.0 along with macOS support (currently being worked on in #73). I think the implementation is close to done, but due to how large the change is I need to do a fair bit of testing before I feel comfortable publishing a release.

Without promising anything, I am thinking a first pre-release should drop around the end of May. However I won't be releasing another stable until 3.0.0 is tested a bit in the real world.