Fix signing failures for dashboard SDK packages

[James Newton-King (JamesNK)]

Description

Failure: The manual internal build for #19999 failed in the Windows Build signing step: build 3071407.

error SIGN004: Signing 3rd party library '.../tools/Dapper.dll' with Microsoft certificate 'Microsoft400'.
error SIGN004: Signing 3rd party library '.../tools/OpenTelemetry.Instrumentation.AspNetCore.dll' with Microsoft certificate 'Microsoft400'.
error SIGN004: Signing 3rd party library '.../tools/SQLitePCLRaw.core.dll' with Microsoft certificate 'Microsoft400'.

Why: Dashboard persistence added in #18924 brought Dapper, OpenTelemetry instrumentation, and SQLite binaries into the Aspire.Dashboard.Sdk.* package payloads. These files had no explicit rules in eng/Signing.props, so Arcade assigned its default Microsoft400 certificate and rejected the third-party assemblies.

The failure did not appear on main because automatic main builds use PostBuildSign=true. Arcade consequently omits managed NuGet packages from the signing inputs, and the current rolling publishing flow does not add another managed-package signing step.

Manual and release builds use PostBuildSign=false, which recursively signs and validates managed NuGet package contents. The manual build therefore exercised the release signing path and caught a failure that would also occur in a release build.

Fix: Classify the affected dashboard dependencies as 3PartySHA2, consistent with the repository's other third-party binaries.

Fixes # (issue)

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?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • 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
  • No

[github-actions]

🚀 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 -- 20027

Or

• Run remotely in PowerShell:

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

[Copilot]

🟢 Approval recommended

The mappings are complete, unique, and consistent with existing third-party signing rules.

Pull request overview

Adds missing third-party signing classifications for Dashboard dependencies to prevent SIGN004 failures.

Changes:

• Maps Dapper, OpenTelemetry ASP.NET Core instrumentation, and SQLitePCLRaw assemblies to 3PartySHA2.

File summaries

File	Description
eng/Signing.props	Adds third-party certificate mappings for Dashboard assemblies.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0
• Review effort level: Balanced

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Ankit Jain (radical)]

Thank you!

[github-actions]

Tests selector

1 / 99 PR test projects · 0 PR jobs · 0 advisory-only targets, from 1 changed file.

Selected PR test projects (1 / 99)

Infrastructure.Tests

Selected PR jobs (0)

none

Advisory workflow impact (0)

none

---

How these were chosen — grouped by what changed

📄 eng/Signing.props (changed)
→ 1 directly: Infrastructure.Tests

Job reasons

none

---

Selection computed for commit e53c2cf.

[Copilot]

🟢 Approval recommended

The signing entries match established repository rules and cover the affected third-party binaries.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 0 new
• Review effort level: Balanced

[aspire-repo-bot]

✅ No documentation update needed.

Step 5 branch taken: docs_optional -> build_or_ci_only

• recommendation from .pr-docs-check/signals.json was docs_optional with signal_count: 0 (no signals triggered; triggered_signals is empty). No path-pattern, diff-content, PR-body, or PR-label signal fired.
• The single changed file, eng/Signing.props (6 additions, 0 deletions), matches the build_or_ci_only allowlist category: it is an engineering/build-infrastructure configuration file under eng/ that classifies specific third-party binaries (Dapper, OpenTelemetry.Instrumentation.AspNetCore, SQLitePCLRaw) as 3PartySHA2 for Arcade signing purposes, fixing an internal release-build signing failure.
• This change has no user-facing behavior, API, CLI, dashboard, or documented-feature impact - it only affects the internal build/signing pipeline. No documentation update on microsoft/aspire.dev is warranted.

[github-actions]

⚠️ CI Failure Analysis: Possible Flaky Test(s)

The CI build failed due to test failure(s) that appear unrelated to the PR changes. These may be flaky tests.

Suspected flaky test(s):

• Aspire.Hosting.Maui.Tests.MauiBuildQueueTests.ReleaseSemaphoreAfterLaunchAsync_AndroidReleasesWhenApplicationCancelsDuringTimeoutStop in job Tests / No-package tests (regular, Aspire.Hosting.Maui.Tests, Hosting.Maui, Hosting.Maui, tests/Aspire.Ho... / Hosting.Maui (windows-latest)
  • Error: System.TimeoutException : The operation has timed out.
  • Stack Trace (first frames):

    at Aspire.Hosting.Maui.Tests.MauiBuildQueueTests.ReleaseSemaphoreAfterLaunchAsync_AndroidReleasesWhenApplicationCancelsDuringTimeoutStop() in D:\a\aspire\aspire\tests\Aspire.Hosting.Maui.Tests\MauiBuildQueueTests.cs:line 1001
       at Aspire.Hosting.Maui.Tests.MauiBuildQueueTests.ReleaseSemaphoreAfterLaunchAsync_AndroidReleasesWhenApplicationCancelsDuringTimeoutStop() in D:\a\aspire\aspire\tests\Aspire.Hosting.Maui.Tests\MauiBuildQueueTests.cs:line 1007
    

  • Why likely flaky: Timeout in an unrelated test area (MauiBuildQueueTests semaphore/timeout handling) not touched by this PR, matching a recurring flaky timeout pattern already seen for sibling tests in the same test class.

Suggested actions:

• Re-run the failed CI jobs to confirm if the failure is intermittent
• If the test continues to fail, consider quarantining it using /quarantine-test <test name> <issue URL>
• Search existing issues to see if this test is already known to be flaky

You can re-run the failed jobs from the workflow run page.