Preserve TypeSystem compatibility with older CLIs

[Adam Ratzman (adamint)]

Description

A TypeScript AppHost using SDK/codegen 13.5 fails under CLI 13.4.6 because the CLI force-shares its older Aspire.TypeSystem contract. The assembly identity still binds, but the newer codegen directly calls a RuntimeSpec.CertificateBundleEnvironmentVariable setter that does not exist in the older contract.

Java codegen has the same compatibility boundary for CommandSpec.UpToDateCheck; CLI 13.4.6 is missing both the property and the CommandUpToDateCheck type.

This probes the additive properties before using them. Current CLIs still pass NODE_EXTRA_CA_CERTS and retain Java's incremental compile check. Older CLIs skip those unsupported capabilities while the rest of code generation continues.

Validation:

• TypeScriptLanguageSupportTests: 14 passed
• Aspire.Hosting.CodeGeneration.Java.Tests: 45 passed
• Aspire.Hosting.CodeGeneration.TypeScript, Aspire.Hosting.CodeGeneration.Java, and Aspire.Hosting.RemoteHost: built with 0 warnings and 0 errors
• Physical CLI 13.4.6 with locally built 13.5 TypeScript SDK/codegen: AppHost started without MissingMethodException; NODE_EXTRA_CA_CERTS was omitted
• Locally built current CLI with the same TypeScript SDK/codegen: AppHost started with NODE_EXTRA_CA_CERTS populated
• Physical CLI 13.4.6 with the previous Java codegen: failed with Could not load type 'Aspire.TypeSystem.CommandUpToDateCheck'
• Physical CLI 13.4.6 with the fixed Java codegen: AppHost and dashboard started successfully

Fixes #19503

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 -- 19506

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

Preserves TypeScript AppHost compatibility when newer SDK codegen runs against an older CLI-provided TypeSystem contract.

Changes:

• Capability-probes optional certificate metadata.
• Adds legacy-contract regression coverage.
• Documents frozen-contract compatibility requirements.

Show a summary per file

File	Description
TypeScriptLanguageSupportTests.cs	Tests legacy runtime-spec compatibility.
Aspire.TypeSystem.csproj	Documents additive-member compatibility rules.
TypeScriptLanguageSupport.cs	Sets certificate metadata only when supported.

Review details

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

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

[Jose Perez Rodriguez (joperezr)]

Change looks good and I understand the reasoning, just left a small comment given I believe there might be another case that we should test if it fails similarly and see if this is something we have to fix too.

[Copilot]

Review details

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

[Adam Ratzman (adamint)]

/backport to release/13.5

[github-actions]

Started backporting to release/13.5 (link to workflow run)

[aspire-repo-bot]

Adam Ratzman (@adamint) backporting to release/13.5 failed, the patch most likely resulted in conflicts. Please backport manually!

git am output

$ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch

Applying: Preserve TypeSystem compatibility with older CLIs
Applying: Handle Java TypeSystem compatibility
Using index info to reconstruct a base tree...
M	src/Aspire.Hosting.CodeGeneration.Java/JavaLanguageSupport.cs
Falling back to patching base and 3-way merge...
Auto-merging src/Aspire.Hosting.CodeGeneration.Java/JavaLanguageSupport.cs
CONFLICT (content): Merge conflict in src/Aspire.Hosting.CodeGeneration.Java/JavaLanguageSupport.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0002 Handle Java TypeSystem compatibility
Error: The process '/usr/bin/git' failed with exit code 128

Link to workflow output

[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.Dashboard.Tests.Model.DashboardClientTests.SubscribeResources_NonProjectedReplicaUpdate_EmitsReplicaOnly in job Tests / Dashboard / Dashboard (ubuntu-latest)
  • Error: Assert.Collection() Failure: Item comparison failure at pos 0. Assert.Equal() Failure: Strings differ. Expected: "syndule-api--0000002" Actual: "syndule-api"
  • Stack Trace (first frames):

    at Aspire.Dashboard.Tests.Model.DashboardClientTests.<>c__DisplayClass22_0.<SubscribeResources_NonProjectedReplicaUpdate_EmitsReplicaOnly>b__1(ResourceViewModelChange change) in /_/tests/Aspire.Dashboard.Tests/Model/DashboardClientTests.cs:line 809
       at Aspire.Dashboard.Tests.Model.DashboardClientTests.SubscribeResources_NonProjectedReplicaUpdate_EmitsReplicaOnly() in /_/tests/Aspire.Dashboard.Tests/Model/DashboardClientTests.cs:line 805
    

  • Why likely flaky: The PR does not modify any Dashboard code or tests; failure is a resource replica ordering/naming race condition, similar to the known flaky pattern in DashboardClientTests.SubscribeResources_ReplicaStartedAtChanged_EmitsParentChange (issue [CI Failure] Flaky: DashboardClientTests.SubscribeResources_ReplicaStartedAtChanged_EmitsParentChange sees duplicate resource change events #19515) involving duplicate/out-of-order resource change events.

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.