Fix signing for aspire-managed bundle payload by joperezr · Pull Request #16016 · microsoft/aspire

joperezr · 2026-04-09T20:37:59Z

Description

Fix the CLI bundle signing gap where aspire-managed was not being signed before being packed into the bundle archive.

Root cause: The managed bundle payload was published via Bundle.proj using a standalone dotnet publish call, which runs outside of Arcade's signing infrastructure. By the time Arcade's signing phase ran during the main build, aspire-managed was already packed inside bundle.tar.gz and embedded in the native aspire CLI binary — unreachable by the signing tooling.

Approach

Split the bundle payload pipeline step into three phases so that aspire-managed goes through Arcade's standard signing infrastructure before CreateLayout packs it into the archive:

dotnet publish — produces the self-contained single-file aspire-managed binary
build.cmd/sh -restore -sign — Arcade's SignToolTask discovers the binary via ItemsToSign globs in Signing.props and signs it in-place using ESRP/MicroBuild
Bundle.proj /t:_RestoreDcpPackage;_RunCreateLayout — creates the bundle.tar.gz archive with the already-signed binary

Changes

eng/Signing.props: Register aspire-managed.exe / aspire-managed in FileSignInfo (certificate mapping) and ItemsToSign (glob pointing at publish output path)
eng/pipelines/templates/BuildAndTest.yml: Replace single Bundle.proj step with the three-phase publish -> sign -> layout flow per target RID
eng/pipelines/templates/build_sign_native.yml: Same restructuring for macOS/Linux native stage. Sign step is conditional on codeSign: true (macOS only; Linux ELF binaries are not signed)

Validation

Tested via internal ADO build 2947441. The signing step reported:

SignToolTask starting.
Signing mode: Real
Round 0: Signing 2 files
Build artifacts signed and validated.

Checklist

Is this feature complete?
- Yes. Ready to ship.
- No. Follow-up changes expected.
Are you including unit tests for the changes and scenario tests if relevant?
- Yes
- No
Did you add public API?
- No
Does the change make any security assumptions or guarantees?
- Yes
  - If yes, have you done a threat model and had a security review?
    - Yes
- No
Does the change require an update in our Aspire docs?
- No

github-actions · 2026-04-09T20:38:14Z

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 16016

Or

Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 16016"

Copilot

Pull request overview

Updates the official build/signing pipeline so the aspire-managed bundle payload is signed before it is archived into bundle.tar.gz and embedded into the native Aspire CLI.

Changes:

Register aspire-managed in eng/Signing.props (FileSignInfo + ItemsToSign) so Arcade signing can discover and sign the published binary.
Restructure the Windows official build template to publish -> sign -> create layout per RID before the main build/sign step.
Apply the same publish -> (conditional) sign -> create layout flow in the macOS/Linux native build template.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
eng/Signing.props	Adds signing metadata and discovery globs for `aspire-managed` publish outputs.
eng/pipelines/templates/BuildAndTest.yml	Splits bundle payload generation to ensure `aspire-managed` is signed before bundling (Windows stage).
eng/pipelines/templates/build_sign_native.yml	Mirrors the pre-bundle signing flow for macOS/Linux native build jobs (signing conditional).

Copilot · 2026-04-09T20:45:11Z

eng/pipelines/templates/BuildAndTest.yml

    - ${{ each targetRid in parameters.targetRids }}:
+      - script: ${{ parameters.dotnetScript }}
+                publish
+                $(Build.SourcesDirectory)/src/Aspire.Managed/Aspire.Managed.csproj
+                -c ${{ parameters.buildConfig }}
+                -r ${{ targetRid }}
+                --self-contained
+                /p:GenerateDocumentationFile=false
+                /p:EnforceCodeStyleInBuild=false
+                $(_OfficialBuildIdArgs)
+                /bl:${{ parameters.repoLogPath }}/PublishManaged-${{ targetRid }}.binlog
+        displayName: 🟣Publish aspire-managed (${{ targetRid }})
+
+      - script: ${{ parameters.buildScript }}
+                -restore -sign $(_SignArgs)
+                -configuration ${{ parameters.buildConfig }}
+                $(_OfficialBuildIdArgs)
+                -projects $(Build.SourcesDirectory)/src/Aspire.Managed/Aspire.Managed.csproj
+                /bl:${{ parameters.repoLogPath }}/SignManaged-${{ targetRid }}.binlog
+        displayName: 🟣Sign aspire-managed (${{ targetRid }})


The Sign aspire-managed step is executed once per targetRid even though ItemsToSign uses a broad $(ArtifactsBinDir)Aspire.Managed\**\publish\aspire-managed.exe glob. With multiple RIDs (win-x64 + win-arm64) this will re-run restore/sign and can end up re-processing already-signed artifacts, increasing build time and introducing avoidable variability. Consider publishing all RIDs first, then running a single signing pass, or narrow the signing invocation/glob to only the current RID’s publish directory.

Good catch on the broad glob. We'll address this in a follow-up PR to keep the scope of this change focused.

Copilot · 2026-04-09T20:45:11Z

eng/pipelines/templates/build_sign_native.yml

+          - script: >-
+              $(Build.SourcesDirectory)/$(dotnetScript)
+              publish
+              $(Build.SourcesDirectory)/src/Aspire.Managed/Aspire.Managed.csproj
+              -c $(_BuildConfig)
+              -r ${{ targetRid }}
+              --self-contained
+              /p:GenerateDocumentationFile=false
+              /p:EnforceCodeStyleInBuild=false
+              /bl:$(Build.Arcade.LogsPath)PublishManaged.binlog


Publish aspire-managed here doesn’t include ${{ parameters.extraBuildArgs }} (which in this pipeline is where $(_OfficialBuildIdArgs) is passed). That means the bundle payload’s aspire-managed binary may be version-stamped differently from the rest of the official build and from the Windows build path. Consider passing the same official/versioning args to the dotnet publish (and, if relevant, the Bundle.proj layout) step so the signed payload matches the build’s intended version metadata.

Good catch - fixed. Added extraBuildArgs to the publish step so it gets the same OfficialBuildIdArgs for consistent versioning.

Split the bundle payload pipeline step into three phases so that aspire-managed goes through Arcade's signing infrastructure before CreateLayout packs it into the bundle archive: 1. dotnet publish - produces the self-contained single-file binary 2. build.cmd/sh -restore -sign - Arcade signs it via ItemsToSign 3. Bundle.proj /t:_RestoreDcpPackage;_RunCreateLayout - creates the tar.gz archive with the already-signed binary Changes: - eng/Signing.props: Add FileSignInfo and ItemsToSign entries for aspire-managed.exe (Windows) and aspire-managed (Linux/macOS) - eng/pipelines/templates/BuildAndTest.yml: Split bundle payload step into publish, sign, and layout steps per RID - eng/pipelines/templates/build_sign_native.yml: Same restructuring for macOS/Linux native stage (sign step conditional on codeSign) Fixes microsoft#15989 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

JamesNK

Clean, well-structured fix. The three-phase publish → sign → layout split correctly ensures aspire-managed is signed before being packed into the bundle archive. Signing.props entries are consistent with existing patterns, and the pipeline restructuring in both BuildAndTest.yml and build_sign_native.yml is correct.

Copilot AI review requested due to automatic review settings April 9, 2026 20:38

Copilot started reviewing on behalf of joperezr April 9, 2026 20:38 View session

Copilot AI reviewed Apr 9, 2026

View reviewed changes

joperezr force-pushed the dev/joperezr/fix-aspire-managed-signing branch from 9416197 to fc6cc93 Compare April 9, 2026 20:55

joperezr force-pushed the dev/joperezr/fix-aspire-managed-signing branch from fc6cc93 to 3060546 Compare April 9, 2026 21:01

github-actions bot mentioned this pull request Apr 9, 2026

[pull requests] Review required #13834

Open

mitchdenny approved these changes Apr 9, 2026

View reviewed changes

joperezr merged commit 4fa5ebe into microsoft:main Apr 9, 2026
524 of 527 checks passed

JamesNK approved these changes Apr 9, 2026

View reviewed changes

eerhardt mentioned this pull request Apr 10, 2026

aspire update fails on latest main on Mac #16043

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix signing for aspire-managed bundle payload#16016

Fix signing for aspire-managed bundle payload#16016
joperezr merged 1 commit intomicrosoft:mainfrom
joperezr:dev/joperezr/fix-aspire-managed-signing

joperezr commented Apr 9, 2026

Uh oh!

github-actions bot commented Apr 9, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 9, 2026

Uh oh!

joperezr Apr 9, 2026

Uh oh!

Copilot AI Apr 9, 2026

Uh oh!

joperezr Apr 9, 2026

Uh oh!

Uh oh!

JamesNK left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

joperezr commented Apr 9, 2026

Description

Approach

Changes

Validation

Checklist

Uh oh!

github-actions bot commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

joperezr Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

joperezr Apr 9, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JamesNK left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions bot commented Apr 9, 2026 •

edited

Loading