Merge release/13.4 to main after v13.4.0 release#17817
Conversation
…7520) Flip StabilizePackageVersion default to true in eng/Versions.props. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix remaining issue 17244 items Preserve legacy auxiliary backchannel resource property serialization unless clients opt in to JSON-valued properties, and remove the unused dashboard start command filter. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address backchannel review feedback Use the existing auxiliary backchannel V3 capability for typed resource properties and stop advertising a new V4 capability. Also limit the watch-resource capability test to the first streamed snapshot so it does not wait for a never-ending watch stream. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Adam Ratzman <adam@adamratzman.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…egration and fix found issues (#17531) * Migrate playground/SqlServerEndToEnd to EF Hosting integration - Remove the `SqlServerEndToEnd.DbSetup` worker project. Its `EnsureCreatedAsync` schema bootstrap is replaced by the `AddEFMigrations` resource model. - Check in the initial migration set. `Aspire.Hosting.EntityFrameworkCore` fixes - Connection-string resolution for the generated `Dockerfile` / bundle env-var now prefers explicit `.WithReference(<db>)` over `.WaitFor(<db>)`. Falls back to wait-based inference only when no references are declared. - `EFCoreOperationExecutor`: read exit code from the strongly-typed `snapshot.ExitCode` instead of parsing the `ExitCode` property string, and publish `ExitCode` on the tool resource's final snapshot update so consumers (including the executor itself) see it. - Tighten `AddEFMigrationsCore` duplicate-registration error messages to talk about "registered for specific DbContext types" / "registered without a context type" instead of "auto-detected". - XML doc cleanup on the public `AddEFMigrations` / `PublishAsMigrationBundle` / `WithMigrationsProject` / `WithMigrationOutputDirectory` / `WithMigrationNamespace` / `RunDatabaseUpdateOnStart` overloads (more accurate summaries, `<c>` instead of quotes, drop obsolete "auto-detected" language, add `<exception>` notes). * Avoid concurrent tool execution --------- Co-authored-by: Andriy Svyryd <Andriy.Svyryd@microsoft.com>
…g.md (#17541) The Spectre.Console [Y/n] confirmation prompt is a single-character reader, not a line reader. Sending TypeAsync("n") + EnterAsync() queues both bytes in the TTY input buffer; when the CLI returns on "n" and tears down its stdin handler before \n is consumed, bash receives the stray \n as an empty command and bumps CMDCOUNT via PROMPT_COMMAND. The test's SequenceCounter then ends up coincidentally agreeing with bash's drifted CMDCOUNT. The next WaitForAspireAddSuccessAsync false-positives on the typed-command prompt header line ([N OK] $ aspire add ...) that bash printed when accepting the command, returning success before aspire add has actually written aspire.config.json. The follow-on Assert reads the file too early and fails. This matches the existing convention in DeclineAgentInitPromptAsync which documents the same race and avoids it by not sending Enter after the single-character answer. Also adds .github/skills/cli-e2e-testing/troubleshooting.md describing the diagnostic recipe (right-artifact selection, cast reconstruction, prompt- counter desync, Y/n race signature) so future agent sessions can recognize the pattern, and references it from SKILL.md. Co-authored-by: Mitch Denny <midenn@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Address remaining PR feedback and fix Docker Compose publish PR feedback from #15691: - Add [ResourceName] attribute to all Add* API name parameters - Replace null-forgiving operator with explicit throw in EndpointsManifestTransformer - Use StringComparison.OrdinalIgnoreCase for route comparison - Fix '.NET Aspire' phrasing in README files Docker Compose publish fixes for Blazor gateway: - Add GatewayOriginReference (IValueProvider + IManifestExpressionProvider) - Use ReferenceExpression for ConfigResponse so publishers emit proper placeholders - Use TextEncoderSettings to escape braces in JSON string values - Simplify Gateway.cs.in (serve ConfigResponse directly, no Replace logic) - Add System.Text.Unicode dependency for brace-escaping encoder Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add OTLP misconfiguration warning to hosted Blazor path The standalone gateway path already logged a warning when telemetry proxying was requested but no HTTP OTLP endpoint could be resolved. The hosted model (ProxyBlazorTelemetry via BlazorHostedExtensions) was missing the equivalent diagnostic. - Add LogWarning in BlazorHostedExtensions.EnsureEnvironmentCallback - Add tests verifying the warning fires (and does not fire) in both scenarios Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Rename ASPIRE_OTLP_PATH_BASE to OTEL_EXPORTER_OTLP_ENDPOINT Use the standard OpenTelemetry environment variable name instead of a custom Aspire-specific one. The value remains a relative path that the WASM client resolves against its page origin to stay same-origin. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Use TestSink/TestLogger instead of custom ListLogger Replace private ListLogger and LogMessage with shared TestSink and TestLogger from Microsoft.Extensions.Logging.Testing. Also moves the OTLP warning in the standalone gateway path before the build step so it is testable, and adds two tests for that path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Filter OTLP proxy traffic from tracing to prevent feedback loop The gateway and hosted server YARP proxies forward /_otlp/* requests to the dashboard. Without filtering, those forwarding requests are themselves traced and exported, creating recursive telemetry entries. - Gateway (Gateway.cs.in): Simplified filter to use Contains for /_otlp/ paths (handles prefix-mounted apps like /app/_otlp/...). Removed IsStaticAssetOrOtlpRequest helper since static asset requests don't go through YARP. - Hosted server (Program.cs): Added PostConfigure to wrap existing OTEL filters with /_otlp/ and /v1/ exclusions. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Javier Calvarro Nelson <jacalvar@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…step (#17543) * Friendly error for 'aspire do --list-steps' without a step 'aspire do' is always step-targeted, so '--list-steps' with no step has no meaningful scope. The validator previously allowed it, which caused the CLI to launch the AppHost and race ahead executing the full pipeline before the CLI could fetch steps and stop. That race surfaced as 'InvalidOperationException: Sequence contains more than one matching element' from AzurePublishingContext (#17526). Tighten the DoCommand validator to always require the step argument (outside the extension host, which prompts interactively). When the user specifies '--list-steps' without a step, emit a friendly, localized error pointing at concrete examples: 'aspire do deploy --list-steps' or 'aspire do publish --list-steps'. Adds StepArgumentRequired and ListStepsRequiresStep entries to DoCommandStrings.resx + Designer.cs and refreshes all xlf translations via UpdateXlf. Tests: - DoCommandTests: new DoCommandWithListStepsAndNoStepArgumentShowsFriendlyError regression case; existing list-steps tests updated to pass a step. - ListStepsTests (E2E): single Docker-backed test now exercises 'aspire do --list-steps' (asserts friendly error and the absence of the 'Sequence contains more than one matching element' crash) plus 'aspire do deploy --list-steps', 'aspire publish --list-steps' and 'aspire deploy --list-steps' against a freshly created starter app. Fixes: #17526 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * List all well-known step names in the friendly error Expand the 'aspire do --list-steps' validation error to enumerate every well-known pipeline step instead of just naming 'deploy' and 'publish'. The step names are hand-maintained in DoCommand alongside a comment pointing at src/Aspire.Hosting/Pipelines/WellKnownPipelineSteps.cs (the CLI does not reference Aspire.Hosting). Updated unit and E2E assertions to match the new message shape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Trim list to build/publish/deploy and add docs link Replace the long enumeration of well-known step names with a short, opinionated suggestion (build, publish, deploy) and a link to the official 'aspire do' reference page on aspire.dev for the full list. This removes the hand-maintained mirror of WellKnownPipelineSteps in DoCommand and simplifies localization since the message no longer takes a format parameter. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address review: fix extension-host bypass and harden E2E asserts - DoCommand validator: fire the ListStepsRequiresStep friendly error for `aspire do --list-steps` even when running in the extension host, because --list-steps does not flow through GetRunArgumentsAsync's interactive step prompt and would otherwise still hit the original pipeline crash from #17526. - ListStepsTests (E2E): replace long, wrap-sensitive substrings with short fragments ("required when using --list-steps", "aspire.dev/") so the assertion does not fail when the friendly error wraps in a narrow Docker terminal. - DoCommandTests: add DoCommandWithListStepsAndNoStepArgumentInExtensionHostShowsFriendlyError to regression-test the extension-host path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Mitch Denny <midenn@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… deploy (#17542) * Validate Helm CLI version (>= 4.2.0) before Kubernetes deploy Aspire's Kubernetes deployment pipeline shells out to 'helm upgrade --install' for the main application chart and for any AddHelmChart(...) resources on a KubernetesEnvironmentResource. Previously we only checked that 'helm' was on PATH; we never asserted the installed Helm version was new enough for the flags and behaviors we depend on (e.g. '--server-side=true --force-conflicts' in the Helm 4 form). Missing or older Helm produced confusing low-level errors like 'unknown flag: --force-conflicts', 'Flag --force has been deprecated', or raw process-spawn failures. Changes: * Add internal HelmVersionValidator that runs 'helm version --short --client', parses the SemVer, and asserts a minimum of Helm 4.2.0. Throws a clear actionable InvalidOperationException (detected vs required + link to https://helm.sh/docs/intro/install/) when the version is too old, unparseable, or the command fails. * Wire the validator into the existing check-helm-prereqs-{env} pipeline step in HelmDeploymentEngine. One check per environment covers both the main chart deploy and AddHelmChart(...) flows since they all DependsOn this step. * Update the 'Helm CLI not found' message to also mention the minimum version requirement. * Remove the now-redundant ad-hoc 'helm version --short' probe at the top of HelmDeployAsync (the prereq step covers it with a much better error). * Promote FakeHelmRunner to a file-scoped test helper that emits canned 'helm version' stdout (defaults to v4.2.0+gfa15ec0) and supports a separate VersionExitCode, so any test exercising the deploy path automatically passes the prereq check. * Add HelmVersionValidatorTests covering: SemVer parsing of v3/v4/v5 outputs with and without '+gitsha' build metadata, rejection of unparseable output, threshold behavior for too-old versions (v4.1.0, v4.0.0, v3.18.0, v3.14.4), and that error messages include the detected version, the required version, and the install docs URL. * Document the Helm 4.2.0+ requirement in the Aspire.Hosting.Kubernetes and Aspire.Hosting.Azure.Kubernetes READMEs. Fixes #16977 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Drop --client flag from helm version invocation The validator was invoking 'helm version --short --client', but the --client flag was removed in Helm 4 (it existed in Helm 2 for the real client/server split, was kept as a no-op in Helm 3, and is unknown in Helm 4). Since this validator's purpose is to enforce Helm 4.2.0 or later, passing --client guarantees a failure against the very minimum version we require, surfacing the exact kind of confusing prereq error this step exists to prevent. Caught by dogfood testing of PR #17491 against a local Helm 4.2.0 install, which produced: Step 'check-helm-prereqs-k8s' failed: 'helm version --short --client' failed (Error: unknown flag: --client). Aspire requires Helm 4.2.0 or later. Switch to 'helm version --short', which produces identical output shape (e.g. v4.2.0+gfa15ec0) on Helm 3 and Helm 4. Add a regression test that records the arguments passed to the runner and asserts --client is never included. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address PR review feedback Three review items from the automated PR reviewer: 1. Gate destroy/uninstall on the same Helm prereq check as deploy. Both 'destroy-helm-{env}' and 'helm-uninstall-{env}' invoke 'helm uninstall', so a missing or too-old Helm would surface as a raw process-spawn / unknown-flag error during teardown instead of the actionable validator message. Add a 'DependsOn(check-helm-prereqs- {env})' on both, and add a regression test that asserts the dependency edge exists. 2. Fix the misleading comment above HelmVersionRegex. The regex is intentionally unanchored so we tolerate banner/shim lines that some shells, oh-my-zsh plugins, or asdf-style shims can prepend to the version output. Update the comment to describe that intent instead of claiming a start anchor that isn't there. 3. Shorten the Helm prerequisite bullets in both Kubernetes README files. Keep the bullet to the requirement itself and move the 'why we validate up front' narrative into a short paragraph below, matching the scannable style of the other hosting READMEs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump E2E Helm install version to v4.2.0 to match new floor The 11 DeployK8s* CLI E2E tests failed on commit d03916c because the container install scripts default HELM_VERSION to v3.17.3 — below the new HelmVersionValidator.MinimumHelmVersion (v4.2.0) that the check-helm-prereqs-{env} pipeline step now enforces. Centralize the version constants in a new tests/Aspire.Cli.EndToEnd.Tests/Helpers/KubernetesE2EVersions.cs so the default lives in one place (and points at the validator's documented minimum), then bump HelmVersion default v3.17.3 -> v4.2.0 (used by every DeployK8s* test and by the quarantined KubernetesPublishTests). HELM_VERSION / KIND_VERSION / KUBECTL_VERSION env-var overrides are preserved so CI can still bump to a newer point release without a code change. The AKS deployment workflow (deployment-tests.yml) still pins azure/setup-helm to v4.1.4 and needs the same bump to v4.2.0 to avoid breaking AKS scenarios under the new validator; that workflow file edit will land in a separate push that has 'workflow' OAuth scope. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump deployment-tests.yml Helm pin to v4.2.0 Match Aspire.Hosting.Kubernetes' new minimum supported Helm version (HelmVersionValidator.MinimumHelmVersion). The check-helm-prereqs-{env} pipeline step now fails fast on older Helm CLIs, so leaving the AKS deployment workflow pinned to v4.1.4 would break every AKS deployment scenario. Also refresh the surrounding rationale comment, which still referred to the historical v3.18 server-side narrative. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Gate AddHelmChart uninstall on prereqs and unify Helm CLI check Address self-review follow-ups on PR #17491: - Per-chart `helm-uninstall-{name}` step (AddHelmChart(...).WithDestroy()) now depends on `check-helm-prereqs-{env}`. Previously only the env-level destroy/uninstall steps were gated, so chart teardown could still hit the cryptic spawn / unknown-flag error the validator exists to prevent. - Drop the standalone PathLookupHelper probe from the prereq step. The validator already wraps spawn failures with the same actionable hint, and routing everything through IHelmRunner lets tests inject a fake without needing real Helm on PATH (fixes 3 pre-existing K8s test failures in environments without helm installed). - Refresh validator catch comment + error wording accordingly. - Drop stale `--client` mention in FakeHelmRunner comment. - Add regression test PerChartHelmUninstallStep_DependsOnCheckHelmPrereqs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Defer Helm version check in destroy-helm-{env} until state is found Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Mitch Denny <midenn@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Add embedded Aspire skills fallback (#17537) Embed a checked-in Aspire skills bundle snapshot for CLI fallback, make agent init warn instead of fail when bundle acquisition is unavailable, and add automation to refresh the snapshot via a draft PR. Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix release backport resource strings Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix Docker compose prepare test runtime dependency Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…rce mapping (#17528) * Bake AspireCliChannel=staging for release-branch builds even when stabilizing The channel-compute step in build_sign_native.yml was checking $versionKind -eq 'release' BEFORE the release-branch regex check. A 13.4 staging build runs from a release/* branch with StabilizePackageVersion=true, which sets DotNetFinalVersionKind=release, so the wrong arm fired and baked AspireCliChannel=stable into the binary. Downstream, aspire init reads CliExecutionContext.IdentityChannel to pick the channel mappings it writes into the workspace nuget.config. With identity=stable there's no Aspire.* → staging-feed mapping, so aspire add tries to resolve packages from nuget.org and either gets 13.3.5 or fails outright (the apphost.cs template pins #:sdk Aspire.AppHost.Sdk@13.4.0+<sha>, which isn't on nuget.org). Swap the conditions so the release-branch check runs first. Release- branch builds are always staging artifacts; only release-shaped non-release-branch builds (effectively none in practice) get stable. Fixes #17527 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add aspireCliChannelOverride pipeline parameter for GA ship builds With release-branch builds now defaulting to 'staging' (so stabilizing dogfood builds aren't mis-baked as 'stable'), there was no remaining path to produce a real 'stable' GA ship binary — the same release/* branch that produces the staging dogfood drops also produces the final ship build, and the pipeline has no other signal to tell them apart. Add a runtime pipeline parameter 'aspireCliChannelOverride' (auto | stable | staging | daily, default auto) to azure-pipelines.yml and thread it through every build_sign_native.yml invocation. When the release manager kicks off the official GA ship build, they set this to 'stable' so the distributed binary bakes AspireCliChannel=stable and aspire init writes the nuget.org-only nuget.config that matches the promoted package set. Routine stabilizing builds leave it on 'auto' and continue to bake 'staging'. The override is validated against the same accepted-channel set that IdentityChannelReader.IsValidChannel enforces at CLI startup so a typo fails the pipeline step rather than producing a binary that refuses to boot. pr-<N> is intentionally excluded from the override set since PR builds always come from the PullRequest reason arm. The unofficial pipeline doesn't get the parameter — its test builds should always derive the channel from branch+reason, and the template's default 'auto' achieves that. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Route stabilizing staging CLI to SHA-derived darc feed The staging-channel synthesis in PackagingService defaulted to PackageChannelQuality.Both for staging-identity CLIs. With Both, useSharedFeed=true and Aspire.* gets routed to the shared dnceng/dotnet9 daily feed -- which only contains prerelease-tagged 13.4.0-preview.* packages, not the stable-shaped 13.4.0 packages produced during release stabilization (StabilizePackageVersion=true). Net effect on the just-shipped staging build of 13.4: `aspire init` drops a NuGet.config pointing Aspire.* at dotnet9, then `aspire add yarp` fails to resolve Aspire.Hosting.Yarp 13.4.0 because dotnet9 doesn't carry it. The packages actually live in the SHA-derived darc-pub-microsoft-aspire-<hash> feed. Fix: when the CLI's identity is staging, derive the synthesized channel's default quality from the CLI build's version shape: - Stable-shaped (no semver prerelease tag) -> Stable, which makes useSharedFeed=false and routes Aspire.* to the SHA-derived darc feed where stabilizing packages actually live. - Prerelease-shaped -> Both (the historical default), since SHA- specific darc feeds are only created for stable release-branch builds and prerelease staging CLIs must use the shared feed. The identity-staging branch runs before the requested/configured branches in the if/else because `init` (and many other commands) calls GetChannelsAsync(requestedChannelName: "staging") when the running CLI's identity is staging -- short-circuiting on the requested branch would re-introduce the bug. The version-shape predicate is injected via constructor so unit tests can deterministically exercise both paths regardless of the test-host assembly's baked InformationalVersion. Validated end-to-end with a locally-built NAOT `aspire` binary (`/p:AspireCliChannel=staging`) + overrideStagingFeed pointing at darc-pub-microsoft-aspire-0f514452: `aspire init` -> `aspire add yarp` now resolves Aspire.Hosting.Yarp 13.4.0 instead of falling back to 13.3.5. Refs #17527 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Pin PackagingService stable-shape predicate to false in CliTestHelper The stabilization-check CI job builds the test host with StabilizePackageVersion=true, which bakes a stable-shaped (no '-') informational version into Aspire.Cli. PackagingService's new identity-staging branch then defaults quality to Stable and requires a SHA suffix in the assembly's InformationalVersion to compute the darc-pub feed URL. Stabilized test-host assemblies don't carry a +sha suffix, so CreateStagingChannel returned null and the UpdateCommand_WhenStagingIdentityRegistersChannel_UsesStagingForUnpinnedProject test fell back to the default channel instead of staging. Default CliTestHelper.PackagingServiceFactory to inject isStableShapedCliVersion: () => false so command-level tests get deterministic prerelease-shaped behavior (quality=Both → shared dotnet9 feed) regardless of how the test host was built. Tests that specifically exercise the stable-shape branch (in PackagingServiceTests) construct PackagingService directly and already pass an explicit predicate. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update eng/pipelines/templates/build_sign_native.yml --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Jose Perez Rodriguez <joperezr@microsoft.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…17556) * Enrich AppHost codegen TypeLoadException diagnostics (#16709) When the installed Aspire CLI ships an �spire-managed server whose bundled Aspire.Hosting.dll is on a different build than the user-restored Aspire.Hosting.CodeGeneration.TypeScript / Aspire.TypeSystem DLLs, reflection-based codegen can throw an empty TypeLoadException that travels back to the CLI with no message and triggers a 60-second backchannel timeout. This change adds three coordinated improvements: 1. Server-side: wrap reflection-load exceptions (TypeLoadException, MissingMethodException, MissingFieldException, BadImageFormatException, FileLoadException, ReflectionTypeLoadException) in a LocalRpcException with a safe, language-agnostic Message and a structured ErrorData payload (TypeName, MemberName, loaded ATS assemblies + informational versions, runtime Aspire.Hosting version, original exception type) carried via JSON-RPC error code -32050. 2. CLI-side: tiered output — emit a yellow pre-flight warning on detected CLI/SDK skew; render only the safe summary + remediation hint by default; reveal the full .NET diagnostic payload under --debug; always log the full payload via LogDebug. Also fault the BackchannelCompletionSource immediately on codegen failure so users no longer wait through the 60s timeout. 3. CLI-side: prune leftover cli.sock.* files older than 24 hours from ~/.aspire/cli/runtime/sockets/ on startup so stale entries don't accumulate from previous crashed runs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address PR review feedback for #16709 - Drop [JsonPropertyName(camelCase)] from CLI diagnostic DTO so the source-generated context deserializes the server's default PascalCase payload. Add a wire-contract test that round-trips the on-the-wire shape and the BackchannelJsonSerializerContext options. - Use SemVersion.ComparePrecedence in IsKnownIncompatibleSkew so SemVer prerelease identifiers are compared (the #16709 case: 13.4.0-preview.1.26218.1 vs 13.4.0-preview.1.26227.1). Update skew tests to cover prerelease and build-metadata cases. - Resolve the runtime Aspire.Hosting version by walking AppDomain.CurrentDomain.GetAssemblies(); never fall back to Aspire.Hosting.RemoteHost (which is what typeof(AssemblyLoader) returned). Add a regression test. - Only the diagnostic-section header keeps the microscope emoji; the continuation lines (Exception, Type, Member, runtime version, loaded assemblies) render as plain text indented under the header. - Tests: use Directory.CreateTempSubdirectory() instead of manually combining Path.GetTempPath() + Guid for CliPathHelper janitor tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix stale CLI socket cleanup matching Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address PR feedback on codegen diagnostics - Catch AppHostCodeGenerationException in sdk dump per-integration path so one failing integration does not abort the full Task.WhenAll batch. - Log the full serialized AppHostCodeGenerationDiagnostic payload in RenderCodeGenerationFailure so debug logs match the XML doc contract. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Sebastien Ros <sebastienros@gmail.com>
* Prefer current CLI template version Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Pin aspire new template version to CLI Ensure CLI-runtime templates selected from explicit package channels use the current bundled CLI/SDK version instead of floating to newer channel packages that can mismatch the bundled AppHost server. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…Folder path (#17573) * Stabilize PrebuiltAppHostServer staging globalPackagesFolder path PackagingService creates the staging channel with ConfigureGlobalPackagesFolder=true so each darc/override feed restore lands in an isolated cache (two staging builds of the same release branch ship as 13.4.0 but from different feeds, and NuGet keys by (id,version) only). PrebuiltAppHostServer was wiring that flag into a TemporaryNuGetConfig whose default globalPackagesFolder value is the relative '.nugetpackages' -- NuGet resolved it under the temp config's own directory, BundleNuGetService baked those temp paths into integration-package-probe-manifest.json, and TemporaryNuGetConfig.Dispose then recursively deleted the cache out from under the manifest. On macOS osx-arm64 polyglot staging builds this surfaced as a hang during DI / assembly loading in aspire-managed. Preserve the per-feed cache isolation behavior and anchor the override at a stable absolute path instead: <ASPIRE_HOME>/.nugetpackages/<first-8-of-CLI-commit-sha> Keying by the truncated commit hash matches the existing darc-pub-microsoft-aspire-<hash> feed URL convention in PackagingService.GetStagingFeedUrl, so the cache key and feed key stay aligned at 8 hex chars. 8 chars is short enough to avoid Windows MAX_PATH blow-ups on deep integration cache trees while keeping SHA collisions negligible. The cache lives under ASPIRE_HOME (not the per-AppHost working directory) so multiple AppHosts on the same machine running against the same staging build can share a single restore -- the unit of isolation here is the staging build, not the individual restore command. Mechanics: - TemporaryNuGetConfig.CreateAsync now accepts an optional globalPackagesFolderValue and propagates it through AddGlobalPackagesFolderToConfigAsync into the merger. - NuGetConfigMerger.AddGlobalPackagesFolderConfiguration takes the optional override and falls back to the workspace-relative default ('.nugetpackages') for the non-temp workspace-merge path. - PrebuiltAppHostServer.ResolveStableGlobalPackagesFolder routes both temp config branches (channel and package-source-override) through the new helper. - VersionHelper.TryGetCurrentCommitHashShort surfaces the truncated SHA from the running CLI's AssemblyInformationalVersion (returns null on clean release builds with no '+sha' suffix; callers fall back to 'default'). - CliPathHelper centralizes the '<ASPIRE_HOME>/.nugetpackages' path so the producer (PrebuiltAppHostServer) and consumer (CacheCommand) can't drift. - CacheCommand.ClearCommand now wipes <ASPIRE_HOME>/.nugetpackages so a wedged staging restore is recoverable through the same UX as every other CLI cache. Tests: - Updated existing PrebuiltAppHostServerTests staging cases to assert the globalPackagesFolder value is absolute and lives outside the temp config directory. - New PrebuiltAppHostServerTests case wires a real PackagingService with overrideStagingFeed on a stable-shaped CLI and pins the same invariant end-to-end. - New TemporaryNuGetConfigTests for the override propagation and for the no-override-when-disabled invariant. - New CacheCommandTests covering the staging cache wipe and the missing-cache no-op path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Key staging globalPackagesFolder cache by feed URL hash The staging globalPackagesFolder fix in the previous commit keyed the \`.nugetpackages\` subdirectory off the CLI's own commit SHA (first 8 hex chars of \`AssemblyInformationalVersionAttribute\`). That handles two darc-shipped staging builds of the same release branch, but it breaks the local-dev case where one CLI is repeatedly retargeted at different \`overrideStagingFeed\` values: the URL changes but the SHA doesn't, so every override silently shares one cache bucket and the second restore reuses the first feed's now-stale \`13.4.0\` assemblies. Switch the cache key to the first 8 hex chars of \`XxHash3\` over the trimmed, lower-cased resolved feed URL: - Override branch passes the explicit \`--source\` URL. - Channel branch passes the channel's \`Aspire*\` mapping source (or the first mapping for forward compatibility). Trim + lower-case before hashing so a stray whitespace from a config file or a hostname-case change doesn't fragment the cache. Non-cryptographic hashing is fine here — the key is a directory name, not a security boundary — and 8 hex chars keep deep integration cache paths well under Windows MAX_PATH while giving ~4 billion buckets, so collisions are negligible across the handful of staging feeds any user ever sees. Removes the now-unused \`VersionHelper.TryGetCurrentCommitHashShort\` helper (added in the previous commit, no remaining callers). Tests: - New \`CliPathHelperTests.ComputeStagingFeedCacheKey_*\` cover determinism, normalization, length defaults, and null/empty input. - Existing \`PrebuiltAppHostServerTests\` strengthened to assert the emitted globalPackagesFolder equals \`<aspireHome>/.nugetpackages/<hash(feed)>\`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Narrow #17564 CLI-pin fallback to prerelease channels PR #17564 introduced a new fallback in TryGetCurrentCliTemplateVersionPackage that pins the template package to the running CLI's SDK version whenever the selected channel is explicit and not local-build. That preserved the intended fix for prerelease channels (daily, staging) where the channel feed filters the running CLI's package out of search results even though the feed can still restore it. But it also fired for the stable channel, where the filter does not apply. For a non-stable-shape CLI (PR build like '13.4.0-pr.X.gY' or a daily-shape preview) invoked with '--channel stable', it forced an unpublishable version into the generated apphost.cs, breaking the SmokeTests LatestCliCanStartStableChannelAppHost and LatestCliCanStartStableChannelTypeScriptAppHost. Exclude the stable channel from the new fallback so that case falls through to the OrderByDescending picker and the user gets the highest shipped stable package they explicitly asked for. The original prerelease-channel motivation ('Aspire.TypeSystem version mismatch when 13.4 CLI floats templates to a 13.5 daily preview') is preserved unchanged. Test updates: - NewCommandChannelResolutionTests.NewCommand_NoChannelArg_ResolvesTemplateFromIdentityChannel gets an expectedVersion theory parameter so the daily case still pins to the CLI version while the stable case asserts the highest shipped stable. - NewCommandChannelResolutionTests.NewCommand_ExplicitChannelArg_OverridesIdentityChannel asserts highest shipped stable (matching the SmokeTest contract). - New NewCommand_ExplicitStableChannel_NonStableCliVersion_FallsBackToHighestShippedStable regression test covers both daily-shape and PR-shape CLI identities. - NewCommandTests.NewCommandWithTypeScriptEmptyTemplatePassesResolvedVersionAndChannelToScaffolding reverts to its pre-#17564 assertion of '9.2.0' from the stable feed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… with legacy fallback (#17571) * Use KnownConfigNames for resource service endpoint URL with legacy fallback Remove hardcoded DOTNET_RESOURCE_SERVICE_ENDPOINT_URL constant from DashboardServiceHost and use KnownConfigNames.ResourceServiceEndpointUrl (ASPIRE_RESOURCE_SERVICE_ENDPOINT_URL) with fallback to KnownConfigNames.Legacy.ResourceServiceEndpointUrl. * Add test for configured resource service endpoint URL --------- Co-authored-by: James Newton-King <james@newtonking.com>
* Fix VS Code AppHost launch path resolution * Use aspire ls for extension AppHost discovery * Refresh AppHost discovery consumers on changes * Use CLI language ids for AppHost discovery * Handle AppHost discovery failures in editor commands * Add TypeScript AppHost launch discovery coverage * Harden AppHost discovery process handling * Honor configured AppHosts in discovery * Consolidate extension AppHost discovery * Fix workspace test path separators * Fix AppHost configured path selection Ensure workspace AppHost selection checks all configured paths before falling back to the single discovered candidate, and add a regression test for multiple config files.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Keep extension-launched AppHost CLI alive Keep the Aspire CLI process alive after VS Code launches an AppHost so the CLI-owned backchannel remains available for the lifetime of the extension-managed debug session. Propagate extension backchannel startup failures instead of returning success. Also ignore generated .modules directories for polyglot AppHosts. * Update extension build and CLI debug logging * Address AppHost launch review feedback Keep extension-managed CLI runs alive only until the AppHost backchannel disconnects, align configured AppHost discovery UX with scanned candidates, restore dynamic debug fallbacks, and return no disposable for async workspace prompts. Restore Yarn 1 frozen install compatibility for extension CI and avoid the npx package-name/bin-name mismatch in localization export. * Address extension discovery review feedback * Stabilize pipeline unit tests without Docker Use the existing fake container runtime resolver in the pipeline unit test context so the built-in container runtime check doesn't depend on Docker availability on CI runners. * Use ordinal comparison in pipeline test provider Keep the fake container runtime service-provider lookup null-safe and explicit. * Revert pipeline test isolation changes --------- (cherry picked from commit 00eff9d) Co-authored-by: David Fowler <davidfowl@gmail.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…d field filter details (#17568) * Update --search option description to include aka.ms link and field filter details * Regenerate xlf files to match current resx values --------- Co-authored-by: James Newton-King <james@newtonking.com>
Graduate the ATS/polyglot surface by removing ASPIREATS001 attributes and obsolete suppressions now that TypeScript/polyglot support is GA for 13.4. Co-authored-by: Sebastien Ros <sebastienros@gmail.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…cribe` for resource streaming (#17579) Backport of #17479 to release/13.4 Conflict resolved in extension/src/views/AppHostDataRepository.ts dispose(): kept both release/13.4's _getAppHostsProcess cleanup and the PR's _stopAllGlobalDescribes() call. Reverted the extension/package.json bump (1.0.9 -> 1.10.0) so the 13.4 extension line stays on 1.0.x. Co-authored-by: adamint <adamint@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Revert the Corepack-specific Yarn invocation added to the extension build so internal Azure Pipelines builds use the configured Yarn executable instead of downloading Yarn from the public registry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…17623) * Fix aspire stop falsely reporting failure on Unix The stop path treated the managing CLI PID as a success condition. On Unix the CLI process can remain observable (for example as an unreaped or briefly lingering process) after the AppHost has already stopped, so aspire stop reported '\u274c Failed to stop apphost.cs' even when shutdown completed successfully. Use the AppHost PID as the success condition, and keep the CLI PID as a shutdown handle that still gets force-killed when present so we never leave a true zombie CLI running after the AppHost is gone. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Signal AppHost directly on Unix and tree-terminate on force-stop The cascade path (signal launcher CLI, let it terminate 'dotnet run', and rely on that to terminate the AppHost) is racy on Unix: if the descendant walk inside 'dotnet run' misses the AppHost, the AppHost is orphaned to PID 1 and HasExited polling can't distinguish a zombie from a live process, so 'aspire stop' falsely reports failure after the full SIGTERM + SIGKILL timeout (~40s). On Unix we now: * Send SIGTERM directly to the AppHost PID so it shuts down through its own IHostApplicationLifetime path. The launcher CLI and dotnet run process exit naturally when their child exits. * Pass killEntireProcessTree:true when force-terminating on Unix. DCP is launched in a separate session there, so force-terminating the AppHost tree doesn't take DCP with it; DCP detects the parent gone and tears down its own children gracefully. Windows behavior is preserved: we keep cascading through the launcher CLI to DCP because DCP is an in-tree descendant of the AppHost on Windows, and a full tree termination would break DCP's orderly resource cleanup. Validation in the repo's Linux container (Ubuntu 24.04 ARM64): * Baseline: 5/25 failures (20%), failures hit the 40s timeout * CLI-visibility-only fix: 1/25 failures (4%) * This change: 0/30 failures, stop wall-time 0.7-2.3s Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: David Negstad <David.Negstad@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…templates (#17637) * Add failing tests for aspire-starter channel resolution on release/13.4 Reproduces the bug where 'aspire new aspire-starter' (and aspire-starter-csharp-typescript) silently resolve Aspire.ProjectTemplates from the Implicit (nuget.org) channel on a daily / staging / release-branch CLI, ignoring CliExecutionContext.IdentityChannel. Passing --channel works because that value is the only thing forwarded into TemplateInputs.Channel today. The new tests pin the contract for both DotNet- and CLI-runtime templates: NewCommand must forward IdentityChannel into inputs.Channel whenever --channel is not passed, so DotNetTemplateFactory.ApplyTemplateAsync uses the identity-matching channel when calling TemplateNuGetConfigService.ResolveTemplatePackageAsync. Coverage across the four shipping identities (pr-<N>, daily, staging, stable) plus three edge cases (unregistered identity falls back to null, explicit --channel overrides identity, --version still forwards identity into inputs.Channel). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Forward IdentityChannel to TemplateInputs.Channel for dotnet-runtime templates When 'aspire new' invoked a TemplateRuntime.DotNet template (e.g. aspire-starter, aspire-starter-csharp-typescript) without an explicit --channel argument, inputs.Channel was left null. That caused TemplateNuGetConfigService.ResolveTemplatePackageAsync to fall back to the Implicit (nuget.org) channel, ignoring the CLI's IdentityChannel. Daily / staging / pr builds would therefore resolve Aspire.ProjectTemplates from nuget.org instead of the channel matching the running CLI. This change mirrors the existing CLI-runtime contract: when --channel is absent and no version-resolution channel was selected, look up the identity channel in the packaging service and forward it to inputs.Channel only when it matches a registered Explicit channel (Implicit matches still resolve to null so the project inherits ambient NuGet configuration). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Consolidate channel precedence into a single resolvedChannelName Address review feedback: collapse the explicitChannelArg / resolvedChannelName / identityChannelName three-way coalesce on TemplateInputs.Channel into a single resolvedChannelName variable with a clear precedence chain (explicit --channel > resolver result > identity). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Explain why identity-channel fallback lives at the call site Document why ResolveIdentityChannelNameAsync is invoked at the TemplateInputs assembly site rather than folded into ResolveCliTemplateVersionAsync: the two paths that need the identity hint (TemplateRuntime.DotNet templates and --version short-circuit) are precisely the ones the resolver never runs on. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…7646) The signed-build verifier ran 'aspire new aspire-starter' after extracting the CLI archive, claiming to exercise 'template engine + bundle self-extraction without requiring a NuGet restore'. That claim was wrong: 'aspire new' resolves template versions via TemplateNuGetConfigService.ResolveTemplatePackageAsync, which always queries a NuGet feed. The step only ever succeeded on release branches because builds were mis-baked with AspireCliChannel=stable, which routed the implicit identity-channel lookup to nuget.org and found a previously-shipped Aspire.ProjectTemplates version. Once #17528 corrected the release-branch builds to bake AspireCliChannel=staging, the identity channel switched to a staging feed that is not reachable from the 1ES signed-build agent, and the step started failing with 'No template versions were found' in the internal build pipeline. This is the same egress reason the TypeScript starter check was already removed for (#17274, tracked in #17345). Re-adding meaningful starter coverage in the signed-build verifier requires either an internal NuGet mirror or a no-network template path. Drop the step (and the corresponding test assertion); the verifier still covers archive layout, sidecar contract, and 'aspire --version' execution. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Accept dev localhost resource service URLs Allow DashboardServiceHost to treat RFC-reserved .localhost subdomains as local resource service endpoints so polyglot AppHosts scaffolded with *.dev.localhost can run. Add unit coverage for local endpoint recognition and a CLI E2E regression test that scaffolds and runs an Express/React polyglot AppHost with dev-localhost URLs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address PR review follow-up comments Co-authored-by: danegsta <50252651+danegsta@users.noreply.github.com> * Use release E2E terminal lifecycle Adapt the backported polyglot dev-localhost CLI E2E test to the release/13.4 test harness, which does not have CliE2ETestHelpers.StartRun. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: David Negstad <David.Negstad@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: danegsta <50252651+danegsta@users.noreply.github.com>
* Add TerminalRun IAsyncDisposable for consistent CLI E2E diagnostics capture (#17576) * Fix CLI Ctrl+C/SIGTERM shutdown: responsive cancellation and double-signal bug (#17588) * Fix CLI Ctrl+C shutdown taking too long during AppHost startup - Make ConsoleCancellationManager.Cancel() non-blocking so Ctrl+C handler returns immediately - Pass cancellation token through to WaitAsync in CancelAppHostStartupAsync so Ctrl+C exits promptly instead of waiting for the full 5s timeout - Support second Ctrl+C for immediate force exit (Environment.Exit) - Add logging support to ConsoleCancellationManager via SetLogger() - Add comprehensive unit tests for ConsoleCancellationManager - Add integration test for RunCommand cancellation during startup timeout Fixes #17569 * Fix review comments: volatile logger, accurate comments, clearer warning * Clean up * Use WaitForSuccessPromptFailFastAsync in CLI E2E tests Replace WaitForSuccessPromptAsync with WaitForSuccessPromptFailFastAsync across all CLI E2E tests. The fail-fast variant detects error prompts immediately and throws instead of hanging for up to 500s waiting for a success prompt that will never arrive. This prevents 10+ minute CI timeouts when a command fails with a non-zero exit code. * Fix double-signal bug and consolidate test helpers - Fix ConsoleCancellationManager double-signal bug: move Console.CancelKeyPress to else branch so it only registers on platforms without PosixSignalRegistration. Previously both handlers fired for the same SIGINT, causing immediate force-kill. - Add SIGQUIT/Ctrl+Break registration for Windows parity. - Remove old WaitForSuccessPromptAsync (no fail-fast) and rename WaitForSuccessPromptFailFastAsync to WaitForSuccessPromptAsync. - Remove duplicate RunCommandFailFastAsync (identical to RunCommandAsync). * Fix stale comment and restrict SIGQUIT to Windows only * Remove unused legacy builder methods and update E2E skill docs * Don't force when debugging * More logging
* Improve dashboard summary log formatting - Indent URL lines with 6 spaces and '- ' prefix so they align with the standard log output indentation - Move container warning to a separate log message with clearer text - Update tests to match new format * Update FrontendBrowserTokenAuthTests to assert new standalone container log message Co-authored-by: JamesNK <303201+JamesNK@users.noreply.github.com> --------- Co-authored-by: James Newton-King <james@newtonking.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: JamesNK <303201+JamesNK@users.noreply.github.com>
Co-authored-by: IEvangelist <7679720+IEvangelist@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Update Foundry hosted agent builder APIs
* Update Foundry hosted agent API surface
* Update Foundry hosted agent tests
* Remove commented-out health check URLs from hosted agent configuration
* Adjust Foundry hosted agent behavior
Consolidate AsHostedAgent usage, update Foundry icons and command rendering, and refresh playgrounds, samples, and tests.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix Foundry hosted-agent run and command icon behavior
Conditionally require/provision Foundry project ACR only for hosted-agent publish or explicit registry override, add regression tests for run/publish paths, and align PromptAgent Send Message icon with ChatSparkle.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Avoid default Foundry ACR in run mode
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Cache JsonSerializerOptions in HostedAgentResourceBuilderExtensions
Avoid allocating a fresh JsonSerializerOptions per Send Message command
invocation, which also defeats JsonSerializer's per-options metadata cache.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Make project positional and add HostedAgentOptions for polyglot
- AsHostedAgent(project, HostedAgentOptions?) is now the polyglot-exported overload
- Action<HostedAgentConfiguration> overload kept as .NET-only for advanced use
- HostedAgentOptions exposes Description, Cpu, Memory, Metadata, EnvironmentVariables
- Polyglot users now get .asHostedAgent(project, { ... }) instead of
.asHostedAgent({ project, configure: async cfg => ... })
- Updated TypeScript, Go, and Java polyglot apphost fixtures to new shape
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Make HostedAgentOptions and its overload internal (ATS-only)
HostedAgentOptions exists only to give polyglot SDK generators a clean
options-bag shape. .NET callers should keep using the richer
Action<HostedAgentConfiguration> overload, so both the DTO and the
overload that takes it are now internal.
To avoid C# overload ambiguity between '.AsHostedAgent(project)' (which
should bind to the public Action overload) and the internal options
overload, the internal method is renamed to AsHostedAgentForExport. The
polyglot-facing name stays as 'asHostedAgent' via [AspireExport(MethodName)].
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Clean up polyglot JSDoc for asHostedAgent
Remove <remarks> blocks from HostedAgentOptions and AsHostedAgentForExport
that were flowing into the generated TypeScript/Go/Java SDK JSDoc and
including C#-only implementation notes plus broken <see cref> renderings
(e.g. \`AsHostedAgent\`\`1). The polyglot codegen concatenates
<summary>+<remarks>, so any C#-implementation chatter pollutes the
generated SDK docs. Replace with plain // source comments that stay in C#.
Also fix the TypeScript polyglot fixture to match the actual generated
signature: when an extension method takes a single optional DTO parameter,
the codegen wraps it in an options bag, so the call shape is
asHostedAgent(project, { options: { ... } }) — not the flat
asHostedAgent(project, { ... }) shape.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix Foundry hosted agent options DTO generation
Mark HostedAgentOptions as an ATS DTO so polyglot SDK generation treats it as a JSON value object instead of a live exported handle. Update the TypeScript validation fixture to use the generated flat options shape.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix Foundry polyglot hosted agent fixtures
Update Go and Java Foundry polyglot AppHosts to match the generated HostedAgentOptions DTO and AsHostedAgent optional-parameter shapes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix Foundry Java hosted agent fixture
Use Double literals for hosted agent CPU and memory options so the generated Java DTO setters compile.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix Foundry API baselines
Regenerate the Foundry ATS and API baselines so the release branch backport exposes the hosted-agent options export and drops the stale withComputeEnvironmentExecutable surface.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: tommasodotnet <tstocchi@microsoft.com>
Co-authored-by: Maddy Montaquila <maleger@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Treat Win32Exception while inspecting process metadata as a stale or non-targetable process so stop monitoring does not fail when an AppHost exits during shutdown. Co-authored-by: Copilot <223556219+Copilot@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 -- 17817Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17817" |
There was a problem hiding this comment.
Pull request overview
Back-merges the release/13.4 branch onto main after the v13.4.0 release, carrying forward release-branch fixes (Foundry hosted-agent behaviors, cross-compute-environment endpoint resolution, CLI staging-channel behavior/caching) plus a small set of post-merge workflow/versioning cleanups.
Changes:
- Adds/propagates cross-compute-environment endpoint resolution support across Azure publishers and Kubernetes, including new/updated tests and snapshots.
- Extends Azure role-assignment wiring to support “fronting” resources via a new
ReferenceRoleAssignmentAnnotation, with additional test coverage. - Updates CLI packaging/channel logic and associated tests/scripts (staging feed routing, temp NuGet config globalPackagesFolder override, cache clear behavior, staging validation scripts), plus workflow retargeting back to
main.
Show a summary per file
| File | Description |
|---|---|
| tests/PolyglotAppHosts/Aspire.Hosting.Foundry/TypeScript/apphost.mts | Adds invocations endpoint and hosted-agent protocol configuration for validation apphost. |
| tests/Aspire.Hosting.Tests/WithEnvironmentTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.Tests/EndpointReferenceTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.Tests/Aspire.Hosting.Tests.csproj | Links shared ComputeEnvironmentEndpointResolver.cs into the test project. |
| tests/Aspire.Hosting.Redis.Tests/AddRedisTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.Qdrant.Tests/AddQdrantTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.PostgreSQL.Tests/PostgresMcpBuilderTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.PostgreSQL.Tests/AddPostgresTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.Milvus.Tests/AddMilvusTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.JavaScript.Tests/AddNodeAppTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.Foundry.Tests/HostedAgentConfigurationTests.cs | Adds coverage for reserved env var validation for hosted agents. |
| tests/Aspire.Hosting.Docker.Tests/DockerComposePublisherTests.cs | Adds Fake container runtime registrations for publish-time image resolution testing. |
| tests/Aspire.Hosting.Azure.Tests/Snapshots/AzureContainerAppsTests.EndpointReferenceToFoundryHostedAgentIsResolvedAcrossComputeEnvironments.verified.json | Adds snapshot for ACA cross-environment endpoint resolution. |
| tests/Aspire.Hosting.Azure.Tests/Snapshots/AzureContainerAppsTests.EndpointReferenceToFoundryHostedAgentIsResolvedAcrossComputeEnvironments.verified.bicep | Adds bicep snapshot for ACA cross-environment endpoint resolution. |
| tests/Aspire.Hosting.Azure.Tests/Snapshots/AzureAppServiceTests.EndpointReferenceToFoundryHostedAgentIsResolvedAcrossComputeEnvironments.verified.json | Adds snapshot for App Service cross-environment endpoint resolution. |
| tests/Aspire.Hosting.Azure.Tests/RoleAssignmentTests.cs | Suppresses experimental diagnostic for role-assignment tests. |
| tests/Aspire.Hosting.Azure.Tests/AzureUserAssignedIdentityTests.cs | Suppresses experimental diagnostic for identity tests. |
| tests/Aspire.Hosting.Azure.Tests/AzurePostgresExtensionsTests.cs | Updates named argument to networkId for allocated endpoints. |
| tests/Aspire.Hosting.Azure.Tests/AzureContainerAppsTests.cs | Adds publish-mode test validating cross-environment endpoint resolution with Foundry hosted agents. |
| tests/Aspire.Hosting.Azure.Tests/AzureAppServiceTests.cs | Adds publish-mode test validating cross-environment endpoint resolution with Foundry hosted agents. |
| tests/Aspire.Hosting.Azure.Kubernetes.Tests/AzureKubernetesFoundryReferenceTests.cs | Adds Kubernetes publish-mode test validating cross-environment endpoint resolution with Foundry hosted agents. |
| tests/Aspire.Cli.Tests/Utils/VersionHelperTests.cs | Adds coverage for exact-version matching behavior when a channel name is specified. |
| tests/Aspire.Cli.Tests/Utils/CliTestHelper.cs | Forces prerelease-shaped CLI version semantics in PackagingService tests to avoid stabilization-dependent behavior. |
| tests/Aspire.Cli.Tests/Packaging/TemporaryNuGetConfigTests.cs | Adds tests for explicit globalPackagesFolder overrides and override-ignored scenarios. |
| tests/Aspire.Cli.Tests/Commands/UpdateCommandTests.cs | Injects informational version override for staging-identity behavior in tests. |
| tests/Aspire.Cli.Tests/Commands/NewCommandTests.cs | Uses GetDefaultSdkVersion() instead of hard-coded SDK version in assertions. |
| tests/Aspire.Cli.Tests/Commands/CacheCommandTests.cs | Adds tests asserting cache clear removes staging NuGet package caches. |
| tests/Aspire.Acquisition.Tests/Scripts/VerifyCliArchivePowerShellTests.cs | Updates expectations after removing offline template creation from verifier script. |
| src/Shared/StringComparers.cs | Renames NetworkID comparer/comparison accessors to NetworkId. |
| src/Shared/ProcessSignaler.cs | Hardens process inspection against races by disposing reliably and catching Win32Exception. |
| src/Directory.Build.props | Bumps package validation baseline version to 13.3.5. |
| src/Aspire.Hosting/Dcp/DcpModelUtilities.cs | Renames local networkID variable to networkId and updates calls. |
| src/Aspire.Hosting/CompatibilitySuppressions.xml | Clears baseline suppressions file content (self-closing suppressions element). |
| src/Aspire.Hosting/ApplicationModel/ResourceUrlsCallbackContext.cs | Renames endpoint context parameter to contextNetworkId. |
| src/Aspire.Hosting/ApplicationModel/ResourceExtensions.cs | Renames endpoint context parameter to contextNetworkId. |
| src/Aspire.Hosting/ApplicationModel/EndpointReferenceAnnotation.cs | Renames context property to ContextNetworkId and adjusts endpoint-name set type. |
| src/Aspire.Hosting/ApplicationModel/EndpointReference.cs | Renames context parameter to contextNetworkId and updates comparison usage. |
| src/Aspire.Hosting/ApplicationModel/AllocatedEndpoint.cs | Renames ctor parameter to networkId and uses it for NetworkID assignment. |
| src/Aspire.Hosting.Valkey/api/Aspire.Hosting.Valkey.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Testing/api/Aspire.Hosting.Testing.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.SqlServer/api/Aspire.Hosting.SqlServer.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Seq/api/Aspire.Hosting.Seq.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Redis/api/Aspire.Hosting.Redis.cs | Updates generated ATS export attribute arguments (and export names). |
| src/Aspire.Hosting.RabbitMQ/api/Aspire.Hosting.RabbitMQ.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Qdrant/api/Aspire.Hosting.Qdrant.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Python/api/Aspire.Hosting.Python.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Oracle/api/Aspire.Hosting.Oracle.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.OpenAI/api/Aspire.Hosting.OpenAI.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Nats/api/Aspire.Hosting.Nats.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.MySql/api/Aspire.Hosting.MySql.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.MongoDB/api/Aspire.Hosting.MongoDB.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Milvus/api/Aspire.Hosting.Milvus.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Maui/api/Aspire.Hosting.Maui.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Kubernetes/KubernetesResource.cs | Delegates cross-environment endpoint reference resolution to owning compute environment. |
| src/Aspire.Hosting.Kubernetes/KubernetesHelmChartResource.cs | Seals Helm chart resource type. |
| src/Aspire.Hosting.Kubernetes/Aspire.Hosting.Kubernetes.csproj | Links shared ComputeEnvironmentEndpointResolver.cs into the Kubernetes project. |
| src/Aspire.Hosting.Keycloak/api/Aspire.Hosting.Keycloak.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Kafka/api/Aspire.Hosting.Kafka.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.JavaScript/CompatibilitySuppressions.xml | Adds JavaScript package validation suppressions. |
| src/Aspire.Hosting.JavaScript/BunAppResource.cs | Seals Bun app resource type. |
| src/Aspire.Hosting.Go/api/Aspire.Hosting.Go.cs | Adds generated ATS surface for Go hosting package. |
| src/Aspire.Hosting.GitHub.Models/api/Aspire.Hosting.GitHub.Models.cs | Updates generated ATS export attribute arguments/export names. |
| src/Aspire.Hosting.Garnet/api/Aspire.Hosting.Garnet.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Foundry/Project/ProjectResource.cs | Adds compute-environment endpoint property expression handling for hosted-agent endpoints and corrects agent naming for deployed hosted agents. |
| src/Aspire.Hosting.Foundry/HostedAgent/HostedAgentConfiguration.cs | Adds reserved environment-variable name validation for hosted agents. |
| src/Aspire.Hosting.Foundry/Aspire.Hosting.Foundry.csproj | Links shared ComputeEnvironmentEndpointResolver.cs into Foundry project. |
| src/Aspire.Hosting.Foundry/api/Aspire.Hosting.Foundry.ats.txt | Updates Foundry ATS baseline export names. |
| src/Aspire.Hosting.EntityFrameworkCore/api/Aspire.Hosting.EntityFrameworkCore.cs | Marks some EF exports as ATS-ignored to avoid conflicts / unsupported shapes. |
| src/Aspire.Hosting.Docker/CompatibilitySuppressions.xml | Clears Docker package validation suppressions file content (self-closing suppressions element). |
| src/Aspire.Hosting.DevTunnels/api/Aspire.Hosting.DevTunnels.cs | Updates generated ATS export attribute arguments/export names. |
| src/Aspire.Hosting.Browsers/api/Aspire.Hosting.Browsers.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Blazor/Resources/BlazorWasmAppResource.cs | Seals Blazor WASM resource type. |
| src/Aspire.Hosting.Blazor/Aspire.Hosting.Blazor.csproj | Marks Blazor hosting package as suppressing final version. |
| src/Aspire.Hosting.Blazor/api/Aspire.Hosting.Blazor.cs | Adds generated ATS surface for Blazor hosting package. |
| src/Aspire.Hosting.Azure/RoleAssignmentResourceAnnotation.cs | Suppresses experimental diagnostic around role assignment resource annotation usage. |
| src/Aspire.Hosting.Azure/ReferenceRoleAssignmentAnnotation.cs | Introduces experimental annotation for implied role assignments across “fronting” resources. |
| src/Aspire.Hosting.Azure/CompatibilitySuppressions.xml | Clears Azure package validation suppressions file content (self-closing suppressions element). |
| src/Aspire.Hosting.Azure/AzureRoleAssignmentResource.cs | Marks role-assignment resource as experimental. |
| src/Aspire.Hosting.Azure/AzureResourcePreparer.cs | Extends role assignment discovery to account for ReferenceRoleAssignmentAnnotation and deduplicates roles per target. |
| src/Aspire.Hosting.Azure.WebPubSub/api/Aspire.Hosting.Azure.WebPubSub.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.Sql/api/Aspire.Hosting.Azure.Sql.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.SignalR/api/Aspire.Hosting.Azure.SignalR.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.Search/api/Aspire.Hosting.Azure.Search.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.Redis/api/Aspire.Hosting.Azure.Redis.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.PostgreSQL/api/Aspire.Hosting.Azure.PostgreSQL.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.OperationalInsights/api/Aspire.Hosting.Azure.OperationalInsights.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.Network/CompatibilitySuppressions.xml | Clears Azure.Network package validation suppressions file content (self-closing suppressions element). |
| src/Aspire.Hosting.Azure.Kusto/api/Aspire.Hosting.Azure.Kusto.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.KeyVault/api/Aspire.Hosting.Azure.KeyVault.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.Functions/api/Aspire.Hosting.Azure.Functions.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.FrontDoor/AzureFrontDoorExtensions.cs | Uses shared compute-environment resolver helper for effective compute environment selection. |
| src/Aspire.Hosting.Azure.FrontDoor/Aspire.Hosting.Azure.FrontDoor.csproj | Links shared ComputeEnvironmentEndpointResolver.cs into FrontDoor project. |
| src/Aspire.Hosting.Azure.FrontDoor/api/Aspire.Hosting.Azure.FrontDoor.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.EventHubs/api/Aspire.Hosting.Azure.EventHubs.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.ContainerRegistry/api/Aspire.Hosting.Azure.ContainerRegistry.cs | Updates generated ATS export attribute arguments/export names. |
| src/Aspire.Hosting.Azure.CognitiveServices/api/Aspire.Hosting.Azure.CognitiveServices.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebsiteContext.cs | Delegates cross-environment endpoint reference resolution to owning compute environment. |
| src/Aspire.Hosting.Azure.AppService/Aspire.Hosting.Azure.AppService.csproj | Links shared ComputeEnvironmentEndpointResolver.cs into AppService project. |
| src/Aspire.Hosting.Azure.AppService/api/Aspire.Hosting.Azure.AppService.cs | Updates generated ATS export attribute arguments and adds WithAcrPullIdentity export. |
| src/Aspire.Hosting.Azure.ApplicationInsights/api/Aspire.Hosting.Azure.ApplicationInsights.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Hosting.Azure.AppContainers/BaseContainerAppContext.cs | Delegates cross-environment endpoint reference resolution to owning compute environment. |
| src/Aspire.Hosting.Azure.AppContainers/Aspire.Hosting.Azure.AppContainers.csproj | Links shared ComputeEnvironmentEndpointResolver.cs into AppContainers project. |
| src/Aspire.Hosting.Azure.AppConfiguration/api/Aspire.Hosting.Azure.AppConfiguration.cs | Updates generated ATS export attribute arguments. |
| src/Aspire.Cli/Utils/VersionHelper.cs | Changes exact-version matching gating logic when channel selection is present. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.zh-Hant.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.zh-Hans.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.tr.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.ru.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.pt-BR.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.pl.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.ko.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.ja.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.it.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.fr.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.es.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.de.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/xlf/AddCommandStrings.cs.xlf | Adds new localization entry for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/AddCommandStrings.resx | Adds new localized resource string for non-interactive exact-match failure. |
| src/Aspire.Cli/Resources/AddCommandStrings.Designer.cs | Adds resource accessor for new non-interactive exact-match message. |
| src/Aspire.Cli/Packaging/TemporaryNuGetConfig.cs | Adds optional globalPackagesFolder override support for temp nuget.config generation. |
| src/Aspire.Cli/Packaging/PackageChannel.cs | Keeps current CLI/SDK version templates during prerelease filtering. |
| src/Aspire.Cli/Packaging/NuGetConfigMerger.cs | Adds default globalPackagesFolder constant and supports override value injection. |
| src/Aspire.Cli/Commands/IntegrationPackageSearchService.cs | Ensures implicit channel remains in searches even when an apphost pins a stable-quality channel. |
| src/Aspire.Cli/Commands/CacheCommand.cs | Extends cache clear to also wipe staging NuGet package caches under ASPIRE_HOME. |
| eng/scripts/verify-cli-archive.ps1 | Removes offline template creation step from signed-build archive verifier. |
| eng/scripts/debug-staging.sh | Adds staging-channel debug helper script (bash). |
| eng/scripts/debug-staging.ps1 | Adds staging-channel debug helper script (PowerShell). |
| eng/scripts/debug-stable.sh | Adds stable-shaped staging debug helper script (bash). |
| eng/scripts/debug-stable.ps1 | Adds stable-shaped staging debug helper script (PowerShell). |
| eng/pipelines/templates/build_sign_native.yml | Adds operator override + fixes branch/identity channel derivation ordering for baked CLI channel. |
| eng/pipelines/azure-pipelines.yml | Wires new aspireCliChannelOverride parameter into native signing jobs. |
| docs/contributing.md | Adds link to CLI staging/stable validation documentation. |
| .github/workflows/generate-api-diffs.yml | Retargets API diff generation workflow back to main. |
Copilot's findings
Files not reviewed (1)
- src/Aspire.Cli/Resources/AddCommandStrings.Designer.cs: Language not supported
- Files reviewed: 171/173 changed files
- Comments generated: 3
| /// <summary> | ||
| /// Gets or sets the network identifier used as context for resolving endpoint addresses. | ||
| /// </summary> | ||
| public NetworkIdentifier ContextNetworkID { get; set; } = KnownNetworkIdentifiers.LocalhostNetwork; | ||
| public NetworkIdentifier ContextNetworkId { get; set; } = KnownNetworkIdentifiers.LocalhostNetwork; |
| /// </summary> | ||
| /// <param name="resource">The <see cref="IResourceWithEndpoints"/> which contains <see cref="EndpointAnnotation"/> annotations.</param> | ||
| /// <param name="contextNetworkID">The ID of the network that serves as the context context for the endpoint references.</param> | ||
| /// <param name="contextNetworkId">The ID of the network that serves as the context context for the endpoint references.</param> |
| /// <param name="contextNetworkID">The ID of the network that serves as the context for the EndpointReference.</param> | ||
| /// <param name="contextNetworkId">The ID of the network that serves as the context for the EndpointReference.</param> | ||
| /// <remarks> | ||
| /// Most Aspire resources are accessed in the context of the "localhost" network (host proceses calling other host processes, |
|
@davidfowl — please review the Foundry hosted-agent resolutions in this merge. Three files combine non-trivially: 1.
|
|
@mitchdenny — please review the resolution of Conflict shape
Both branches mutated the same method, so git produced a conflict hunk covering the entire test body. Picking either side wholesale would have lost the other side's intent. Resolution process
RiskIf main''s renamed test method Could you confirm |
|
@danegsta — please review the resolution of Conflict shape
Resolution process
Resulting section now reads: ### Testing pull request changes
To test changes from a specific pull request locally, see [dogfooding-pull-requests.md](/docs/dogfooding-pull-requests.md) for instructions on installing Aspire CLI and NuGet packages built by that PR's CI run.
To validate how the CLI resolves `Aspire.*` packages for **staging** and **stable** release-branch builds (including making an installed PR build behave like a staging build), see [cli-staging-validation.md](/docs/cli-staging-validation.md).RiskPure prose, no build impact. The risk is a contributor-UX one: if you intended the staging-validation pointer to live in a different section (e.g. closer to the CLI-build instructions, or as its own top-level "Validating release packaging" subsection), the current placement may be misleading. Happy to relocate if you have a preferred spot. |
|
@adamint — please review the resolution of Conflict shape
Both branches touched overlapping regions around extension activation, telemetry hookup, and command registration, so git flagged the file as conflicted. Resolution process
RiskThe risk is the inverse of the usual one: by taking main wholesale, any release-side fix to |
The merge auto-pulled release/13.4's api/*.cs and api/*.ats.txt baselines for 56 pre-existing
packages. These baselines no longer match main's source code (e.g., Foundry's source has
[AspireExport("asHostedAgent")] from #17671 but the release baseline says "asHostedAgentExecutable",
and the release baseline still references the WithComputeEnvironment method that was renamed to
the AsHostedAgent overloads in #17732).
Per repo convention (.github/copilot-instructions.md): api files are regenerated as part of the
release process, not during individual PRs. Reverting to main's state matches what @davidfowl's
forward-port PR #17775 does, and lets the next release run regenerate them.
The 2 net-new api files for the new Aspire.Hosting.Blazor and Aspire.Hosting.Go integrations
are kept as-is (they didn't exist on main).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Foundry validation against @davidfowl's #17775 + stale
|
This reverts commit dd519dc.
|
❌ CLI E2E Tests failed — 109 passed, 1 failed, 2 unknown (commit ❌ Failed Tests
View all recordings
📹 Recordings uploaded automatically from CI run #26797967144 |
|
✅ No documentation update needed. docs_required → already documented by name: This is the
|
Resolved conflicts after release/13.4 forward-port (#17817) landed: - src/Aspire.Cli/Packaging/PackagingService.cs: combined using blocks from both sides (kept System.Globalization, System.Reflection, System.Security, added Aspire.Cli.Acquisition from main). - src/Aspire.Cli/Commands/CacheCommand.cs: auto-merged but new code pulled in from main references CliPathHelper; added the missing using Aspire.Cli.Utils;. Built Aspire.Cli + Aspire.Cli.Tests clean; BaseCommandTests, PackagingServiceTests, and CacheCommandTests (100 tests) pass. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Replacement for #17804, which was opened directly from
release/13.4and therefore couldn''t take conflict resolution or post-merge cleanup commits. This PR brings the 43 release-branch commits fromrelease/13.4forward ontomainnow that v13.4.0 has shipped, plus the cleanups noted below.The single commit on this branch is the merge commit. Squashing would lose the release-branch commit history on
main(it would re-author 43 release commits as a single squash from me, breaking attribution,git log --follow, and downstream backport tooling). Please use "Create a merge commit" when merging this PR.Conflict resolution (33 files)
Equivalent backports — kept main's commit identity:
tests/Aspire.Cli.EndToEnd.Tests/ChannelUpdateWorkflowTests.cs(Fix Y/n input race in ChannelUpdateWorkflowTests + add CLI E2E troubleshooting doc #17533 ≡ [release/13.4] Fix Y/n input race in ChannelUpdateWorkflowTests + add CLI E2E troubleshooting doc #17541)tests/Aspire.Dashboard.Tests/LoggingHelpersTests.cs(Improve dashboard summary log formatting #17595 ≡ [release/13.4] Improve dashboard summary log formatting #17640, Restore dotnet watch dashboard auto-launch signal #17610 ≡ [release/13.4] Restore dotnet watch dashboard auto-launch signal #17653)extension/src/editor/AspireEditorCommandProvider.ts,extension/src/utils/appHostDiscovery.ts, and the three correspondingextension/src/test/*.test.tsfiles (Fix VS Code AppHost launch path resolution #17408 ≡ [release/13.4] Fix VS Code AppHost launch path resolution #17560 backport)Release-only forwards — preserved release content:
HostedAgentBuilderExtension.cs,HostedAgentOptions.cs,HostedAgentExtensionTests.cs, Foundry api baseline files,apphost.mtsPrebuiltAppHostServerstagingglobalPackagesFolderpath →CliPathHelper.csUpdateCommandTests.csMain-only forwards — preserved main content:
AspireSkillsInstaller.cs)TerminalRunIAsyncDisposable(SmokeTests.cs,ChannelUpdateWorkflowTests.cs)extension.ts)[AspireExport("asHostedAgent", ...)]rename)Hybrid — manual splice:
docs/contributing.md— kept main''s restructured layout and inserted release''s staging-validation paragraphsrc/Aspire.Hosting.Foundry/HostedAgent/HostedAgentBuilderExtension.cs— took release as base, then re-applied Fix Foundry ATS baseline #17671tests/Aspire.Cli.Tests/Commands/UpdateCommandTests.cs— took main, then injected Route staging-identity CLI to its darc feed regardless of version shape #17743''sOverrideCliInformationalVersionConfigKeyblockPost-merge cleanups in this PR (requested by review)
StabilizePackageVersiontrue→falseeng/Versions.propsrelease/13.4by #17520 to ship 13.4.0;mainmust stay in preview mode for the 13.5 cycleref: release/13.4→ref: main,base: release/13.4→base: main.github/workflows/generate-api-diffs.ymlmainagainrelease/13.3→release/13.4(all occurrences).github/workflows/backmerge-release.ymlrelease/13.4intomain.github/workflows/milestone-assignment.ymlmain→13.5,release/13.4→13.4.xValidation
git diff --checkclean — no stray conflict markers./build.cmd /p:SkipNativeBuild=true— 0 warnings, 0 errors in ~6 minutes.resxFollow-up
cc @microsoft/aspire-engineering-systems