Summary
A TypeScript AppHost using SDK/codegen 13.5 fails when run by Aspire CLI 13.4.6:
Method not found: 'Void Aspire.TypeSystem.RuntimeSpec.set_CertificateBundleEnvironmentVariable(System.String)'
CLI and SDK versions are intended to tolerate this skew, with features requiring a newer CLI unavailable rather than preventing the AppHost from running.
Root cause
Aspire.TypeSystem is force-shared from the CLI's bundled AppHost server so polyglot contracts keep one type identity across the default and integration assembly load contexts. Its strong-name AssemblyVersion is intentionally frozen at 13.4.5.0.
#19365 added the additive RuntimeSpec.CertificateBundleEnvironmentVariable property. The 13.5 TypeScript codegen directly invokes that setter while creating its runtime spec. Under CLI 13.4.6, binding succeeds because the frozen assembly identity matches, but the force-shared 13.4.6 RuntimeSpec does not contain the new setter. The invocation therefore throws MissingMethodException.
The freeze documentation says additive members do not require an assembly-version bump. That is only safe for SDK-side assemblies if they probe newly added members before invoking them when they may run against an older bundled contract.
CI gap
The certificate tests use an aligned 13.5 CLI, TypeSystem, and codegen. There is no N-1 CLI × N SDK compatibility row. API compatibility correctly classifies the new property as additive, and assembly-skew diagnostics do not run because the equal-version assembly bind succeeds; the failure occurs later inside GetRuntimeSpec().
Proposed fix
Set the optional certificate metadata through a runtime property probe. A current CLI still receives NODE_EXTRA_CA_CERTS; an older CLI does not expose that feature but can continue code generation. Add a regression test using a legacy runtime-spec shape with no certificate property.
Summary
A TypeScript AppHost using SDK/codegen 13.5 fails when run by Aspire CLI 13.4.6:
CLI and SDK versions are intended to tolerate this skew, with features requiring a newer CLI unavailable rather than preventing the AppHost from running.
Root cause
Aspire.TypeSystemis force-shared from the CLI's bundled AppHost server so polyglot contracts keep one type identity across the default and integration assembly load contexts. Its strong-nameAssemblyVersionis intentionally frozen at13.4.5.0.#19365 added the additive
RuntimeSpec.CertificateBundleEnvironmentVariableproperty. The 13.5 TypeScript codegen directly invokes that setter while creating its runtime spec. Under CLI 13.4.6, binding succeeds because the frozen assembly identity matches, but the force-shared 13.4.6RuntimeSpecdoes not contain the new setter. The invocation therefore throwsMissingMethodException.The freeze documentation says additive members do not require an assembly-version bump. That is only safe for SDK-side assemblies if they probe newly added members before invoking them when they may run against an older bundled contract.
CI gap
The certificate tests use an aligned 13.5 CLI, TypeSystem, and codegen. There is no
N-1 CLI × N SDKcompatibility row. API compatibility correctly classifies the new property as additive, and assembly-skew diagnostics do not run because the equal-version assembly bind succeeds; the failure occurs later insideGetRuntimeSpec().Proposed fix
Set the optional certificate metadata through a runtime property probe. A current CLI still receives
NODE_EXTRA_CA_CERTS; an older CLI does not expose that feature but can continue code generation. Add a regression test using a legacy runtime-spec shape with no certificate property.