Skip to content
This repository has been archived by the owner on Jul 5, 2024. It is now read-only.

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

Closed
caesay opened this issue Jan 7, 2022 · 7 comments
Labels
enhancement New feature or request

Comments

@caesay
Copy link
Member

caesay commented Jan 7, 2022

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)

@caesay caesay added the enhancement New feature or request label Jan 7, 2022
@theresia-tobii
Copy link

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
Copy link
Member Author

caesay commented Jan 17, 2022

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
Copy link

  • 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
Copy link
Member Author

caesay commented Apr 4, 2022

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.

peppy added a commit to peppy/osu that referenced this issue Apr 25, 2022
Closes ppy#17965.

Note that this will cause a second osu! icon to appear after running the
application (after any update). As per the inline comment, this will
eventually be resolved via clowd/Clowd.Squirrel#24.

I do think having context menus working is more important than duplicate
icons.

Note that for anyone who already has a pinned taskbar icon, it will need
to be manually unpinned and repinned after a future update to actually
fix this issue.

Thanks to @caesay for help with investigation.
@caesay
Copy link
Member Author

caesay commented May 2, 2022

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

@caesay caesay closed this as completed May 2, 2022
@hutterm
Copy link

hutterm commented May 16, 2022

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

@caesay
Copy link
Member Author

caesay commented May 16, 2022

@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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants