Repository navigation
feat(update): download and verify the new build instead of only linking to it - #1
Merged
Merged
Conversation
…ng to it The opt-in check already told the user that a newer release existed, but the only thing it did about it was open the release page in a browser. The app is distributed as a self-contained zip, so the user still had to find the asset, download it, check the checksum by hand and copy the file over. The check now does that part itself: it picks the self-contained win-x64 zip (the framework-dependent one needs .NET 10 installed, so it is never the one to hand out), downloads it, checks it against the SHA256SUMS.txt published on the same release, and unpacks it into %LOCALAPPDATA%\QuickText\Updates\<version>. The running program is deliberately left alone. These are single-file self-contained executables and Windows locks a running exe, so overwriting it in place fails with a sharing violation and leaves a half-written install behind. The new build is unpacked into a folder of its own and the user is told where it is; replacing the old one is their call, made with the old one closed. A folder that already holds a verified build is not fetched again, so a user who ignores the notice does not pay for the download on every start.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The opt-in check already told the user that a newer release existed, but the only thing it did about it was open the release page in a browser. The app ships as a self-contained zip, so the user still had to find the asset, download it, check the checksum by hand and copy the file over.
This change does that part itself:
win-x64zip (never theneeds-dotnet10one, which refuses to start without the runtime installed),SHA256SUMS.txtpublished on the same release — a mismatch is thrown away, not unpacked,%LOCALAPPDATA%\QuickText\Updates\<version>\and says where the new program is.The running program is never replaced. These are single-file self-contained executables and Windows locks a running exe, so overwriting it in place fails with a sharing violation and leaves a half-written install behind. The new build lands in a folder of its own and the user is told where it is; replacing the old one is their call, made with the old one closed.
A folder that already holds a verified build is not fetched again, so a user who ignores the notice does not pay for the download on every start.
The check stays opt-in and off by default, and it is still the only thing in the app that goes online.
The dead
Msg.UpdateAvailablestring is gone with the old flow;Msg.UpdateReadyandMsg.UpdateVerifyFailedtake its place in all 18 languages.