Repository navigation
fix(setup): recover incomplete self-contained Builder runtimes - #2449
Conversation
Joey-Magnus
left a comment
There was a problem hiding this comment.
builder_ready (setup.c:529) checks the 12 startup files, which matches the csproj (SelfContained=true, PublishSingleFile=false), and it's used in all three places that matter. The tests are thorough.
One fix before merge: the new error after unpacking (setup.c:776) drops the old antivirus hint and the folder path. Defender quarantining files is a known cause (the "Wacatac" worklist row), and in that case "Run the setup again" just loops. Please put the hint and the path back.
Validate required startup components before installed reuse, staged publication and fast launch. Exercise real Win32 file readiness and reject independent boundary-removal mutations without launching any Builder fixture. Assisted-by: OpenAI Codex
Capture the native production error dialog using an authored missing-runtime fixture; distinguish it from complete installation validation. Assisted-by: OpenAI Codex
Exercise the accepted home and publication helpers while checking the actual failure retains the antivirus hint and staging folder. Assisted-by: OpenAI Codex
Refresh the authored native error-dialog capture and explain how the reported staging path helps investigate repeated quarantines. Assisted-by: OpenAI Codex
Include the production readiness helper and authored required files; verify an incomplete portable runtime never starts a process and recovers once restored. Assisted-by: OpenAI Codex
4171896 to
66f5ba8
Compare
|
Restored the quarantine/history hint, affected executable and staging-folder paths, and refreshed the controlled native screenshot. Rebased on |
…ry button can be pressed scripts/launcher/dummy.ps1 makes a world afresh at each start of scripts/launcher/live.ps1 (build/launcher/live): the test rig's releases (rig.py) served on 127.0.0.1, v2.1.0 installed with the real setup beside it, a game folder holding v2.1.0 whose game is a stand-in that says "Play works" (dummygame.c), and an empty game file chosen for Build. The builders' python.exe is the rig's stand-in for make_game.py, so Update installs v2.2.0's builder from that server and "builds" the folder in about 10 seconds; -Fail makes every build stop half way. - Builders.DummyReleases (HOOKSHOT_DUMMY_RELEASES, development only): a release's builder is installed from <url>list-<tag>.txt, and the launcher's own downloads are refused (a first builder from GitHub, AMD's FSR runtime). - rig.py: its releases and v2.1.0 have the runtime files the setup checks since NotRexed#2449 (builder_ready), without which the setup refused every made-up builder; tests/builder_launcher/rig/run.ps1's setup checks pass again. - fakepy.c: FAKE_GAME_EXE, the game a build from game files makes. Checked off-screen against the made-up releases: Update (v2.1.0 -> v2.2.0, builder installed from the local server), Build (a new folder at v2.2.0 with the stand-in game) and a failing Update (the folder left at v2.1.0) all end as they should, the real %LOCALAPPDATA%\HookshotBuilder is untouched, and no stand-in is left running. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
198 commits behind: the portable installations (NotRexed#2367), the update guard for a folder newer than the latest release (NotRexed#2519) and the builder's update fixes since (NotRexed#2141, NotRexed#2449, NotRexed#2528) all touch the files this branch changes. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DBGH7x7hn8ibuEU45oPKo2
…or launching it Windows setup accepted a version folder with HookshotBuilder.exe and its installed marker even when the Flutter runtime, its data folder or the Rust engine was missing, so an incomplete extraction or an antivirus quarantine was reused, published, or launched as if it were complete. Ported from upstream 2dfe901 (NotRexed#2449) to this fork's Flutter package: one builder_ready check (the exe plus flutter_windows.dll, data/icudtl.dat, data/app.so, hookshot_engine.exe and hookshot_engine.dll, each a non-empty file) now guards installed reuse, staged publication and fast launch. The staged failure names the quarantine/history and says no complete installation was published. The portable-home machinery of upstream NotRexed#2367 is not part of this change. Tests: builder/rust/tests/setup_readiness.rs cuts builder_ready out of the production source and runs it against authored Win32 file-attribute doubles (complete package, each missing component, empty file, folder in place of a file, empty or missing exe, no folder to anchor names), plus source checks for the three call sites and the diagnostic. Game-free; no Windows executable, installer or game data. Assisted-by: opencode (DeepSeek V4.1 Flash 1017)
Summary
Windows setup can accept a Builder executable and installed marker even when its private .NET runtime is missing. Incomplete installations now enter recovery, and incomplete staging stops before publication. The diagnostic keeps the affected paths and possible antivirus quarantine cause so retrying setup is actionable; the original cause in #2423 remains unconfirmed.
Technical changes
Validation
Head
66f5ba8d8c89ba14330f8fbf118ff0d9b7ff5f47, rebased on main6f4f28ac.Earlier-head validation
On
4171896d, all applicable hosted checks passed. A disposable controlled installation with EXE/marker present and coreclr.dll missing recovered through actual downloads, verified/unpacked pinned official v2.1.0, and ran its private .NET8.0.33 managed CLI help with exit0; original source files stayed unchanged. This was not the reporter's unconfirmed missing-file cause or a full game test, and has not been repeated on the rebased head.Full suites on
dead3fcdversus base3e95ca68: Windows378/3/31 versus376/3/31; Linux385/2/25 versus385/2/23, with matching failing check identities. These are historical results, not checks of the current head.