Skip to content

A made program can't start: Make copies only the runner's executable, which has needed HexIDE.Standalone.dll since AOT was dropped #1971

Closed

Description

@imojenisys

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.

🤖 Generated with Claude Code

Activity

  1. added
    bugSomething isn't working
    compileBuilding a VB6 project, including driving real vb6.exe and parsing what it says.
    mediumT-shirt size, never time. An open design decision AND a coupled fix. Anchor: PR #242.
    on Oct 25, 2026
  2. added this to the Alpha milestone on Oct 25, 2026
  3. imojenisys commented on Oct 25, 2026

    @imojenisys
    ContributorAuthor

    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.
    • Make copies that one file, renamed, beside the project archive. The requiredNativeFiles loop 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.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.

    🤖 Generated with Claude Code

  4. imojenisys commented on Oct 25, 2026

    @imojenisys
    ContributorAuthor

    v0.2.0 is affected.

    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.

  5. self-assigned this
    on Oct 25, 2026
  6. imojenisys commented on Oct 25, 2026

    @imojenisys
    ContributorAuthor

    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.

  7. imojenisys commented on Oct 25, 2026

    @imojenisys
    ContributorAuthor

    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.
    • Make copies that one file, renamed, beside the project archive. The native-library lists and FindStandaloneRuntime are 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 names standalone/ and the runner file.
    • MadeProgramTests:
      • 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.
    • The README's "Making a program" section (from 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): drop the known-issue line, and say the runner is one file.
    • The changelog entry: programs made with v0.2.0 don't start, and need making again after this fix (see the release check above).
    • A red check: the test against a multi-file runner, as v0.2.0 ships. It wasn't run.
    • Full suites on Windows and WSL, and a live check through the IDE.
  8. imojenisys commented on Oct 25, 2026

    @imojenisys
    ContributorAuthor

    In progress on branch fix/1971-single-file-runner, now on main after #1947 landed in batch 31.

  9. added a commit that references this issue on Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingcompileBuilding a VB6 project, including driving real vb6.exe and parsing what it says.mediumT-shirt size, never time. An open design decision AND a coupled fix. Anchor: PR #242.

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions