Use a 'current' directory instead of 'app-{version}' for the latest app version
See original GitHub issueProblem
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 #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 thecurrent
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)
Issue Analytics
- State:
- Created 2 years ago
- Reactions:3
- Comments:7 (4 by maintainers)
@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.
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.