You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
A made program can't start: Make copies only the runner's executable, which has needed HexIDE.Standalone.dll since AOT was dropped #1971
Found during #1947's live check (2026-10-25, Windows, a Debug build of fix/1947-make-runtime).
What happened. With the runner published by dotnet publish HexIDE.Standalone -f net10.0 -o <IDE>/standalone/, File → Make Project1 completed, and wrote this:
Project1.exe 194560 (the runner's apphost, renamed)
Project1.dll 579 (the project archive)
av_libglesv2.dll, libHarfBuzzSharp.dll, libSkiaSharp.dll
The made program exits at once with -2147450726 (0x8000809A). Run from a console, the .NET host says:
The application to execute does not exist: '<made folder>\HexIDE.Standalone.dll'.
Why. Make copies only the runner's executable and its three native libraries (ProjectService.MakeProject's copy loop over requiredNativeFiles). That was enough while the runner was a single native file published with AOT. ac57ae7 (#30, 2026-08-16) turned AOT off, and since then HexIDE.Standalone.exe is an apphost. It needs HexIDE.Standalone.dll, its dependencies, .deps.json and .runtimeconfig.json beside it, and Make copies none of them.
The release packages publish the runner with -r but not single-file (publish.yml), so a program made from a release is most likely the same. I haven't checked that.
Expected: a made program that starts.
Possible fixes:
Copy the runner's whole publish folder beside the made program. Its archive name already differs from HexIDE.Standalone.dll, so nothing collides.
Or publish the runner single-file (PublishSingleFile with IncludeNativeLibrariesForSelfExtract), for the runner only. publish.yml explains why the IDE can't be single-file, and none of those reasons is the runner's.
A test should start a made program, at least on Windows, rather than check the files Make wrote. The existing Make tests use stand-in files that are copied, never run (SourceEncodingPersistenceTests), and that is how this went unnoticed.
Supervisor: on the Alpha milestone, and the fix is the single-file runner. Make is a headline feature, and a made program that doesn't start breaks it end to end, probably in the releases too.
Publish HexIDE.Standalone single-file and self-contained (PublishSingleFile, SelfContained, IncludeNativeLibrariesForSelfExtract), per runtime identifier, for the runner only. VB6's Make EXE gives the user one program, not a folder of runtime libraries, and the reasons publish.yml records for keeping the IDE multi-file don't apply to the runner. A made program should run on a machine with no .NET and no HexIDE.
publish.yml and the README instructions publish the runner that way on every leg, so a release can make programs.
A test that starts a made program, as the issue says, at least on Windows CI: Make a Sub Main project that writes a marker file or sets an exit code, run the result, and assert on it.
Check a current release first: if programs made from it fail the same way, say so in the changelog entry.
I checked hexide-windows-amd64.zip, verified against the release's own SHA-256. Its standalone/ folder holds a multi-file runner: HexIDE.Standalone.exe, which is an apphost, plus HexIDE.Standalone.dll, .deps.json, .runtimeconfig.json and the managed dependencies.
I copied what Make copies (the runner as Project1.exe, the three native libraries, and a project archive as Project1.dll) into an empty folder and started it. It exits with -2147450726, and the host reports The application to execute does not exist: '<folder>\HexIDE.Standalone.dll'.
The self-contained packages are published the same way, with -r and without single-file, so they should behave the same. I haven't downloaded them.
Paused, and unassigned, so this is free to pick up. Usage is near the weekly limit. It isn't unstarted, though. Work in progress is on the pushed branch fix/1971-single-file-runner (commit afb77b8, not a PR). The branch is stacked on #1947's branch, so rebase it onto main once #1947 merges.
Done on the branch, following the supervisor's direction above:
The runner publishes single-file and self-contained whenever it is published (_IsPublishing). A publish with no -r takes the SDK's own runtime identifier. On Windows that gives one HexIDE.Standalone.exe of about 110 MB, plus .pdb files, which release staging already deletes.
It makes a Sub Main project with the real runner, starts the program, and asserts exit code 0 and the marker file it writes.
It runs on Windows when a runner is published to artifacts/make-runtime/standalone/ (or HEXIDE_MAKE_RUNTIME), and skips visibly otherwise.
A separate [Fact] fails when HEXIDE_REQUIRE_MADE_PROGRAM=1 and the runner is missing.
It passed locally on Windows against a runner built from the branch, alongside MakeProjectMessageTests and SourceEncodingPersistenceTests (73 of 73).
Still to do:
publish.yml: publish the runner once per runtime identifier, and copy it into both flavours in place of the two per-flavour publishes. macOS signing of the single-file Mach-O is unverified.
build.yml: on the Windows leg of build-ide-desktop, publish the runner to artifacts/make-runtime/standalone/, and set HEXIDE_REQUIRE_MADE_PROGRAM: '1' on the ViewModel tests.
Activity
imojenisys commentedon Oct 25, 2026
Supervisor: on the Alpha milestone, and the fix is the single-file runner. Make is a headline feature, and a made program that doesn't start breaks it end to end, probably in the releases too.
HexIDE.Standalonesingle-file and self-contained (PublishSingleFile,SelfContained,IncludeNativeLibrariesForSelfExtract), per runtime identifier, for the runner only. VB6's Make EXE gives the user one program, not a folder of runtime libraries, and the reasonspublish.ymlrecords for keeping the IDE multi-file don't apply to the runner. A made program should run on a machine with no .NET and no HexIDE.requiredNativeFilesloop and its per-platform lists go away, along with Make Project's runtime-missing notice points to README instructions that don't exist, and a plain publish puts the native libraries where Make doesn't look #1947's "which file is missing" check, which becomes a check for the one runner file.publish.ymland the README instructions publish the runner that way on every leg, so a release can make programs.Sub Mainproject that writes a marker file or sets an exit code, run the result, and assert on it.Check a current release first: if programs made from it fail the same way, say so in the changelog entry.
🤖 Generated with Claude Code
imojenisys commentedon Oct 25, 2026
v0.2.0 is affected.
I checked
hexide-windows-amd64.zip, verified against the release's own SHA-256. Itsstandalone/folder holds a multi-file runner:HexIDE.Standalone.exe, which is an apphost, plusHexIDE.Standalone.dll,.deps.json,.runtimeconfig.jsonand the managed dependencies.I copied what Make copies (the runner as
Project1.exe, the three native libraries, and a project archive asProject1.dll) into an empty folder and started it. It exits with-2147450726, and the host reportsThe application to execute does not exist: '<folder>\HexIDE.Standalone.dll'.The self-contained packages are published the same way, with
-rand without single-file, so they should behave the same. I haven't downloaded them.imojenisys commentedon Oct 25, 2026
In progress on branch
fix/1971-single-file-runner, stacked on #1947's branch (fix/1947-make-runtime), since both change Make's runtime lookup.imojenisys commentedon Oct 25, 2026
Paused, and unassigned, so this is free to pick up. Usage is near the weekly limit. It isn't unstarted, though. Work in progress is on the pushed branch
fix/1971-single-file-runner(commit afb77b8, not a PR). The branch is stacked on #1947's branch, so rebase it onto main once #1947 merges.Done on the branch, following the supervisor's direction above:
_IsPublishing). A publish with no-rtakes the SDK's own runtime identifier. On Windows that gives oneHexIDE.Standalone.exeof about 110 MB, plus.pdbfiles, which release staging already deletes.FindStandaloneRuntimeare gone. Make Project's runtime-missing notice points to README instructions that don't exist, and a plain publish puts the native libraries where Make doesn't look #1947's notice now namesstandalone/and the runner file.MadeProgramTests:Sub Mainproject with the real runner, starts the program, and asserts exit code 0 and the marker file it writes.artifacts/make-runtime/standalone/(orHEXIDE_MAKE_RUNTIME), and skips visibly otherwise.[Fact]fails whenHEXIDE_REQUIRE_MADE_PROGRAM=1and the runner is missing.MakeProjectMessageTestsandSourceEncodingPersistenceTests(73 of 73).Still to do:
publish.yml: publish the runner once per runtime identifier, and copy it into both flavours in place of the two per-flavour publishes. macOS signing of the single-file Mach-O is unverified.build.yml: on the Windows leg ofbuild-ide-desktop, publish the runner toartifacts/make-runtime/standalone/, and setHEXIDE_REQUIRE_MADE_PROGRAM: '1'on the ViewModel tests.imojenisys commentedon Oct 25, 2026
In progress on branch
fix/1971-single-file-runner, now on main after #1947 landed in batch 31.WIP: a single-file runner, so a made program starts (hexide-io#1971)
WIP: publish the single-file runner in releases and CI, and document …
Batch 34: #2007, #2009, #2011, #2014 (#2018)