Make CLI bundle self-extraction conditional based on distribution mode#15941
Make CLI bundle self-extraction conditional based on distribution mode#15941
Conversation
Add SelfExtractingBundle MSBuild property (default false, true for dotnet-tool) that gets baked into the assembly as metadata. BundleService reads the flag and skips self-extraction when disabled, relying on pre-extracted layouts for archive/installer distributions. Agent-Logs-Url: https://github.com/microsoft/aspire/sessions/62830c5d-e5f0-4741-a5f9-5dc8dc84a82a Co-authored-by: radical <1472+radical@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 -- 15941Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15941" |
…-extraction-conditional
When IsSelfExtracting=false, EnsureExtractedAsync was unconditionally short-circuiting, even if no layout existed on disk. This broke archive distributions where the binary still has an embedded bundle but the layout wasn't pre-extracted. Now it checks DiscoverLayout first and falls back to extraction when the layout is missing. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The previous CI run had E2E test failures with 'Arithmetic overflow while reading bundle' in aspire-managed, which is unrelated to our code changes. The aspire-managed binary is built independently and our extraction code is unchanged from main. Other PRs pass E2E tests, suggesting this was a transient artifact corruption. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
…actingBundle Replace the AssemblyMetadataAttribute + reflection approach with a compile-time DefineConstants approach. The AssemblyMetadataAttribute was causing 'Arithmetic overflow while reading bundle' errors in native AOT builds, likely due to how ILC handles assembly-level attributes alongside large embedded resources. The new approach defines SELF_EXTRACTING_BUNDLE as a compile-time constant when SelfExtractingBundle=true, avoiding any reflection or assembly metadata in the native binary. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
|
Re-running the failed jobs in the CI workflow for this pull request because 1 job was identified as retry-safe transient failures in the CI run attempt.
|
Remove the #if SELF_EXTRACTING_BUNDLE compile-time conditional and DefineConstants MSBuild property. Hardcode IsSelfExtracting => false to diagnose if the DefineConstants approach was causing the bundle corruption CI failures. The SelfExtractingBundle MSBuild property is retained for future use when the dotnet-tool distribution (Aspire.Cli.Tool.csproj) enables self-extraction. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🎬 CLI E2E Test Recordings — 56 recordings uploaded (commit View recordings
📹 Recordings uploaded automatically from CI run #24158324292 |
…-extraction-conditional
Description
The bundled CLI always self-extracts
bundle.tar.gzat runtime viaBundleService.EnsureExtractedAsync, even for archive/installer distributions where the layout is already on disk. This forces write permissions to the install directory unnecessarily.This PR introduces a
SelfExtractingBundleMSBuild property baked into the binary as assembly metadata, soBundleServicecan skip extraction for distributions that don't need it.MSBuild (
Aspire.Cli.csproj):SelfExtractingBundledefaults tofalsetruewhenIsCliToolProject=true(dotnet-tool viaAspire.Cli.Tool.csproj)[assembly: AssemblyMetadata("SelfExtractingBundle", "...")]Runtime (
BundleService):IsSelfExtractingproperty reads the metadata at startupEnsureExtractedAsyncshort-circuits whenIsSelfExtractingisfalseExtractAsync(used byaspire setup) still checksIsBundleonly — explicit extraction remains available regardless of distribution modeNo changes needed in
eng/clipack/Common.projitems— it publishesAspire.Cli.csprojdirectly (not the Tool project), soSelfExtractingBundlecorrectly defaults tofalse.Checklist
Warning
Firewall rules blocked me from connecting to one or more addresses (expand for details)
I tried to connect to the following addresses, but was blocked by firewall rules:
dnceng.pkgs.visualstudio.com/usr/share/dotnet/dotnet dotnet build src/Aspire.Cli/Aspire.Cli.csproj /p:SkipNativeBuild=true(dns block)If you need me to access, download, or install something from one of these locations, you can either: