[release/13.5] Exclude unused hex1bpty.exe from published CLI archives - #19557
Conversation
Hex1b ships a hex1bpty.exe PTY host in its win-x64/win-arm64 native assets.
Aspire never takes that path: DCP owns every PTY we surface and
Aspire.TerminalHost only proxies the byte stream DCP already produces, so the
helper is ~5 MB of dead weight in each Windows CLI archive and inside every
Windows aspire.exe bundle payload. It also shows up as an unexplained second
executable in the winget submission, where every binary in the archive is run
through executable and malware checks.
Filter it out of publish for src/ projects. Test projects are untouched because
they drive real terminals through Hex1b.Automation, which does need the helper.
Unix keeps libhex1binterop.{so,dylib}, the termios/ioctl shim the TUI P/Invokes.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19557Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19557" |
There was a problem hiding this comment.
Pull request overview
Excludes Hex1b’s unused Windows PTY helper from published Aspire CLI artifacts.
Changes:
- Removes
hex1bpty.exeduring publish. - Provides a
PublishHex1bPtyHost=trueopt-out. - Preserves Unix native assets and test behavior.
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
This comment has been minimized.
This comment has been minimized.
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
Tests selector (audit mode)The full test matrix and all jobs still run in audit mode. The tests and jobs below are what selective CI would run under enforcement. Runs the full test matrix + all jobs (ALL) — a rule matching 'eng/Versions.props' selects ALL Selection computed for commit |
a22cec2
into
release/13.5
|
✅ No documentation update needed. Step 5 branch taken: excluded → base_branch_is_release, head_branch_is_backport, title_release_prefix, body_backport_marker This PR is a backport (title Triggered signals: none (signal_count = 0; recommendation was Exclusion reasons (from signals.json): base_branch_is_release (base ref is No docs PR drafted. |
Backport of #19554 to release/13.5
/cc Mitch Denny (@mitchdenny)
Customer Impact
The Windows CLI archives (
aspire-cli-win-{x64,arm64}-*.zip) ship a ~4.9 MBhex1bpty.exethat Aspire never executes. It is Hex1b's out-of-process PTY host, which Hex1b only launches when it owns the pseudo-terminal for a child process — Aspire never takes that path, because DCP creates and owns every PTY we surface andAspire.TerminalHostonly proxies the byte stream DCP is already producing.Beyond the wasted download (~4.9 MB in the archive, plus the same again inside
aspire.exebecauseAspire.Managedpicks it up and is embedded as the bundle payload), it shows up as an unexplained second executable in the WinGet submission, where every binary in the archive is run through executable and malware checks. That is what stalled the 13.5.0 WinGet publish in microsoft/winget-pkgs#421219. Backporting keeps 13.5 servicing releases publishable without walking an unused binary past store validation each time.Testing
Verified against real CI-built archives on the source PR (run
32425648015):win-x64andwin-arm64contain onlyaspire.exe+Aspire.TypeSystem.xml, whilelinux-x64andosx-arm64still containlibhex1binterop.{so,dylib}(the termios/ioctl shim the TUI does need).Compared against the same workflow on
main(run32411678172), the sole delta is the removed 4,914,688-bytehex1bpty.exe:mainaspire.exeAspire.TypeSystem.xmlhex1bpty.exeAlso A/B verified locally (with and without the new
PublishHex1bPtyHostopt-out) that this target is what removes the file, and thatAspire.Managed— the bundle payload embedded inaspire.exe— is covered too. No product code changes, so no new tests.Risk
Very low. Build-only: a single MSBuild target that drops one never-executed file from
ResolvedFileToPublish, scoped tosrc/so test projects are untouched (the CLI and deployment E2E tests drive real terminals throughHex1b.Automation, which does need the PTY host). Unix native assets are unaffected.libsodium.*, which is present in 13.5 archives but no longer onmain, is not touched by this change.PublishHex1bPtyHost=truerestores the old behavior if a shipping project ever needs the helper.Regression?
Yes — new in 13.5. The shipped 13.4.6 Windows archive contains only
aspire.exe,Aspire.TypeSystem.xml, andlibsodium.dll, with nohex1bpty.exe. The cause is thatsrc/Aspire.Cli/Aspire.Cli.csprojgained a directHex1bPackageReferencein 13.5 (there is none onrelease/13.4), which pulled Hex1b's Windows native asset into the CLI publish output for the first time.