Merge release/13.4 to main after v13.4.1 release#17883
Closed
aspire-repo-bot[bot] wants to merge 21 commits into
Closed
Merge release/13.4 to main after v13.4.1 release#17883aspire-repo-bot[bot] wants to merge 21 commits into
aspire-repo-bot[bot] wants to merge 21 commits into
Conversation
* [release/13.4] Add Aspire CLI npm package release integration Backport of #17297 to release/13.4. Adds npm packaging and release-pipeline publishing for the Aspire CLI: pack/sign/verify of the @microsoft/aspire-cli pointer package and its seven RID packages, npm install validation steps, npm publish + registry validation stages in release-publish-nuget.yml, npm pipeline variables, and CLI npm-install detection/update messaging. The docs/release-process.md changes from the source PR are intentionally omitted: on main they are interleaved with VS Code extension / Marketplace release documentation that does not apply to release/13.4 (the VS Code extension is not released from this branch). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix Aspire CLI npm signing scope (#17770) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…json (#17820) The embedded CLI template src/Aspire.Cli/Templating/Templates/empty-apphost/aspire.config.json shipped a profiles block that duplicated apphost.run.json. The canonical template in src/Aspire.ProjectTemplates/templates/aspire-apphost-singlefile/aspire.config.json intentionally has no profiles (per Damian's design): aspire run / dotnet run apphost.cs honor apphost.run.json when present, so aspire.config.json for the C# Empty template should only carry { "appHost": { "path": "apphost.cs" } }. Updated NewCommandTests to: - assert that aspire.config.json has no profiles block and pins appHost.path = apphost.cs - assert that apphost.run.json carries the launch URLs (plain localhost and dev.localhost variants) - drop the now-unused AssertHttpsApplicationUrlMatches helper Fixes #17660 Co-authored-by: Mitch Denny <midenn@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Defer explicit-start DCP registration Avoid evaluating execution configuration callbacks for session-scoped explicit-start resources until they are manually started. Persistent explicit-start resources are still registered eagerly, but manual start now patches the existing DCP object instead of recreating it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Refine explicit-start DCP lifecycle 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>
* Add proxyless endpoint on-demand allocation Allow dynamic proxyless container endpoints to allocate a target-port fallback when an endpoint reference requires an allocated endpoint before container creation. Disable the on-demand allocator once container ports are built so later resolution continues to use DCP service updates. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Log proxyless endpoint fallback allocation Log when a dynamic proxyless container endpoint is resolved before container creation and Aspire assigns the public port to match the target port. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Use atomic proxyless allocator cutoff Replace the endpoint allocation cutoff lock with an atomic exchange so BuildContainerPorts remains the point where on-demand proxyless endpoint allocation stops. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Remove proxyless allocator clear helper Use the atomic OnDemandAllocatedEndpointProvider setter directly at the BuildContainerPorts cutoff instead of a dedicated clear wrapper. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Simplify proxyless allocator provider storage Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Move proxyless allocator cutoff into port build Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Move on-demand endpoint allocation ownership to resource Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Clarify on-demand endpoint allocation lifecycle Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Simplify resource-owned endpoint allocation Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Move proxyless allocation cutoff after configuration 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>
* Fix Redis persistent lifetime startup Use Redis endpoint target ports for TLS startup arguments so container command-line evaluation does not wait for allocated public ports before the container exists. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bound Redis argument evaluation test Use a bounded wait around the Redis argument evaluation regression test so the test fails promptly if endpoint resolution deadlocks again. 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 <223556219+Copilot@users.noreply.github.com>
aspire-repo-bot
Bot
added
the
area-engineering-systems
aspire-repo-bot
Bot
requested review from
JamesNK,
danegsta,
davidfowl,
karolz-ms and
mitchdenny
as code owners
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17883Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17883" |
* Add per-integration persistence tests Co-authored-by: danegsta <50252651+danegsta@users.noreply.github.com> * Add CLI persistent container E2E test Co-authored-by: danegsta <50252651+danegsta@users.noreply.github.com> * Fix persistence test compilation Co-authored-by: danegsta <50252651+danegsta@users.noreply.github.com> * Address persistence test review feedback Co-authored-by: danegsta <50252651+danegsta@users.noreply.github.com> * Add Azure emulator mode coverage Co-authored-by: danegsta <50252651+danegsta@users.noreply.github.com> * Address emulator mode test review feedback Co-authored-by: danegsta <50252651+danegsta@users.noreply.github.com> * Stabilize persistent container tests Use an isolated user-secrets store for persistent container test runs so integration defaults can persist generated parameters across AppHost restarts. Avoid the CI container registry override for Azurite because the mirrored tag is unavailable. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Stop forcing test container registry in persistent helper Let persistent container tests use the same container registry configuration path as normal TestDistributedApplicationBuilder usage instead of forcing the test mirror from the helper. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Use start waits in persistent container E2E Avoid blocking the test server on dependency health checks in the CLI E2E scenario. The endpoint verification already retries real Redis, PostgreSQL, and Azure Storage operations after the resources have started. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Compare Docker container IDs in persistent tests Assert persistent container tests observe container.lifetime=Persistent and compare the actual container.id across AppHost runs instead of the stable DCP resource ID. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Read synthetic user secrets in persistent tests Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Allow persistent tests to opt into test registry Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Make persistent test secrets cleanup best effort Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix persistent container E2E networking Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Propagate CLI E2E start timeout 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> Co-authored-by: David Negstad <David.Negstad@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
… update manifest tags (#17958) * fix(winget): unblock WinGet Manifest job on locked-down 1ES agents The `🟣Install winget CLI` step on the WinGet Manifest job fails on the 1ES `1es-windows-2022` pool with: An attempt was made to access a socket in a way forbidden by its access permissions. (cdn.winget.microsoft.com:443) The step ran `Repair-WinGetPackageManager -Latest -Force -AllUsers` to (re)install the winget CLI, which downloads the Microsoft.DesktopAppInstaller MSIX from cdn.winget.microsoft.com. That CDN is not reachable from the locked-down 1ES pool, so the PowerShell step exits 1, `🟣Prepare WinGet manifests` is skipped, and `🔒 🟣Publish WinGet manifests` then fails because the manifest directory was never produced. The whole job aborts before any manifests reach the artifact share. This is the failure on release/13.4 builds 2989641, 2989822, 2990382, 2990509, 2990688. Replace the install/repair step with a probe-only step that records whether winget happens to be pre-installed on the image, and hardcode the downstream `prepare-manifest-artifact.ps1` call to `Offline` ValidationMode. The script tolerates a missing winget in Offline mode (logs a warning, still produces the manifest artifact) but hard-fails in Full mode — and Full mode is unreachable on this pool because winget cannot be installed. Drop the `skipUrlValidation` template parameter, the only callers (azure-pipelines.yml, azure-pipelines-unofficial.yml), and the `_PackagesPublished` variable composed only to feed it. Manifest validation is intentionally delegated to upstream `microsoft/winget-pkgs` CI — see the new "Validation model" section in eng/winget/README.md for what upstream checks (schema, binary AV scan, URL + SmartScreen, SHA256, install/uninstall in a clean VM). This matches the pattern used by every other Microsoft repo publishing to WinGet (PowerToys, terminal, winget-create itself, which also runs on the same 1ES `windows-2022` pool and likewise does not invoke winget in CI). End-to-end probe + prepare + publish path validated on internal build 2990922 (a sibling branch that exercised the WinGet Manifest job via a stage-condition override). Real-prod validation occurs when this lands on release/13.4 and the stage condition naturally includes it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update WinGet manifest tags The WinGet package template still categorized the Aspire CLI with the `dotnet` tag. Replace that tag with `csharp` and `typescript` so the package metadata better matches supported Aspire application languages. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * docs(winget): note GH Actions install + smoke-test path The 'Validation model' section originally implied the Aspire side does only generation + opportunistic `winget validate`. In fact `.github/workflows/prepare-installer-artifacts.yml` also runs `dogfood.ps1 -Force` (real `winget install --manifest` from the freshly built archive) plus a smoke test (`aspire new` + restore) against the installed shim on every PR. Document that. Clarify that the install-only path catches issues `winget validate` does not (SHA mismatch, broken `InstallerSwitches`, missing `Commands`), while the full install/uninstall round-trip remains an upstream-CI responsibility. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Ankit Jain <radical@gmail.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix persistent container endpoint allocation Default persistent container endpoints to proxied unless proxy support is disabled, and remove delayed proxyless container endpoint allocation in favor of target-port public port defaults. Preserve endpoint and connection string event timing from release/13.3 and add coverage for the KeyVault emulator-style health check path.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Restore health check URI binding timing Set HTTP health check URIs during BeforeResourceStartedEvent again so surrogate resource builders that forward startup events continue to initialize their health checks. Add DCP coverage for the KeyVault-emulator-style surrogate pattern.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump Aspire patch version to 13.4.3 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Preserve blocking endpoint allocation dispatch Keep ResourceEndpointsAllocatedEvent dispatch aligned with release/13.4 so subscriber exceptions propagate and endpoint allocation callbacks complete before startup proceeds.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Stabilize Kafka persistent reuse test port Use a fixed public Kafka port for the persistent reuse test and let the shared persistent-container helper disable DCP test port randomization when a test needs explicit ports to remain stable.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Re-connecting should be part of DCP request retry * Simplify implementation * Additional test * Update patch version * Improve comment * Test improvements Make sure files used by tests are created in isolated location and deleted no matter test outcome * Optimizing the read for the kubeconfig file
|
|
||
| await app.StopAsync(); | ||
| } | ||
| [Fact] |
#18093) * Use build artifact downloader for npm summaries The release pipeline consumes npm validation summaries from source builds that published them as build/container artifacts. Download them with DownloadBuildArtifacts instead of the pipeline artifact shortcut so existing source builds can be released without re-spinning.\n\nCo-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix npm preflight success exit code Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Allow either required npm publish owner Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Improve npm CLI package metadata * Remove npm README launcher implementation detail * Relax npm ESRP approver validation * Require npm ESRP publish aliases * Address npm release validation review feedback * Simplify npm publish skip parameters Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix CLI E2E package version selection Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Use explicit package version without prerelease flag Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Match exact local hive package files Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Handle CLI update prompt in channel E2E Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Wait past CLI update prompt in channel E2E Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Address npm release review feedback - Extract npm package READMEs into separate template files and render them via a shared Expand-Template helper instead of inline here-strings. - Move the npm ESRP alias validation into eng/scripts/validate-npm-release-aliases.ps1 (dot-sourceable) with executable unit tests covering empty/whitespace owners, multiple approvers, missing required owner, owner/approver overlap, non-Microsoft email rejection, @microsoft.com stripping, and effective-set emission. The release job runs with checkout: none, so the helpers stay mirrored inline and a test keeps the two copies in sync. - Forward NpmPublishOwners/NpmPublishApprovers to the validation step via env: so operator-supplied values are treated as data, not interpolated into the inline script. - Give NpmPublishOwners/NpmPublishApprovers/NpmRegistryPropagationDelayMinutes working defaults and mark them [Advanced] so an unattended queue submission passes validation. - Replace pack-script source-text assertions with tests that run the script across all supported RIDs and assert the generated package.json, package map, and READMEs. - Clarify the local-hive vs --prerelease comment in KubernetesDeployTestHelpers. - Update the npm-cli-package spec to describe the new parameter defaults and validation script. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix npm CLI README markdown lint Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Harden npm release alias validation Reject unsafe alias values before emitting Azure Pipelines logging commands and keep the inline release-pipeline validation body covered by the script sync test. Also clarify npm self-update README wording. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix npm release pipeline env expansion Quote queue-time npm release alias parameters when forwarding them through the validation step environment so Azure Pipelines treats the values as strings during release-job expansion. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Avoid object expressions in release pipeline scripts Compute installer-only logging inside PowerShell instead of embedding a template function result in the inline script scalar, which Azure Pipelines reports as an Object-to-String conversion error at powershell: |. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Use standard MicroBuild release job context Remove the unsupported templateContext.mb.publish.feedSource object from ReleaseJob; dnceng release-job expansion reports it as an Object-to-String conversion failure at the first powershell step. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Download release artifacts explicitly Avoid passing current-pipeline artifact objects through ReleaseJob templateContext.inputs; download the prepared artifacts explicitly at the start of ReleaseJob to bypass dnceng release-job object conversion during YAML expansion. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Avoid wildcard template expression in release script Remove the literal ${{ parameters.* }} text from an inline PowerShell comment because Azure Pipelines expands template expressions inside block scalars and treats the wildcard as the parameters object. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Jose Perez Rodriguez <joperezr@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
radical
approved these changes
Jun 12, 2026
… MCP tools (#18150) * Filter resources with resource.excludeFromMcp from CLI MCP tools Resources marked with the resource.excludeFromMcp property are now excluded from all MCP tool results: - ListResourcesTool filters them from resource listings - ListConsoleLogsTool and ExecuteResourceCommandTool reject requests targeting excluded resources - ListStructuredLogsTool, ListTracesTool, and ListTraceStructuredLogsTool filter out telemetry from excluded resources - McpResourceToolRefreshService skips excluded resources Added McpToolHelpers with IsExcludedFromMcp, CheckResourceExcludedAsync, GetExcludedResourceNamesAsync, and GetResourceNotAvailableMessage helpers. Includes comprehensive unit tests covering all filtering scenarios. * Add ListTraceStructuredLogsTool exclusion tests and E2E test - Add two tests for ListTraceStructuredLogsTool filtering: - FiltersExcludedResourceLogs: verifies excluded resource logs are removed from trace-scoped structured log results - ReturnsAllLogs_WhenNoResourcesExcluded: verifies no filtering when no resources are excluded - Add doesNotContainMarker parameter to CallAgentMcpToolAsync helper - Add AgentMcpExcludeFromMcpTests E2E test that verifies list_resources excludes resources marked with ExcludeFromMcp() * Use quoted markers in E2E test for precise JSON matching * Avoid redundant connection lookup in exclusion checks Add overloads of CheckResourceExcludedAsync and GetExcludedResourceNamesAsync that accept IAppHostAuxiliaryBackchannel directly. Update ListConsoleLogsTool and ExecuteResourceCommandTool to use the connection they already obtained, eliminating a redundant GetSelectedConnectionAsync + GetResourceSnapshotsAsync call per request. * Use StringComparers.ResourceName and extract CreateExcludedResult helper * Fix AgentMcpExcludeFromMcp E2E test: disable Redis cache The test was timing out because the Redis container's health check never passed in the Docker-in-Docker CI environment, causing webfrontend (which has WaitFor(cache)) to stay stuck in Waiting state. Redis is irrelevant to this test — it only verifies ExcludeFromMcp() filtering. Disabling Redis removes the container dependency. --------- Co-authored-by: James Newton-King <james@newtonking.com>
…t-cli specifically (#18240) * Add coding agent telemetry detection Detect known coding agents from environment variables and include the detected agent name on Aspire CLI main telemetry. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update src/Aspire.Cli/Telemetry/CodingAgentDetector.cs * Report copilot-cli specifically & update tests to work in test explorer * Enhance CodingAgentDetector to support GitHub Copilot CLI and VS Code agents; update tests for new detection logic --------- Co-authored-by: Damian Edwards <damian@damianedwards.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The playwrightCliVersion configuration value is forwarded to npm as the package version specifier. Previously any non-empty string would be passed through, so a typo or unsupported shape (a range, an npm dist-tag like 'latest', a v-prefixed version, etc.) would surface as a generic 'failed to resolve' error from npm. Validate the override with SemVersion.TryParse using SemVersionStyles.Strict and fail fast with a clear message that names the configuration key and the offending value when it is not a valid SemVer 2.0 version. Co-authored-by: Mitch Denny <mitchell.denny@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…903 (#18204) * Bump StreamJsonRpc to 2.25.25 to clear MessagePack NU1903 The aspire-starter template was emitting NU1903 for transitive MessagePack 2.5.192 (GHSA-hv8m-jj95-wg3x / CVE-2026-48109) because the shared StreamJsonRpc 2.22.23 dependency pulled it in. Updating StreamJsonRpc to 2.25.25 brings MessagePack 2.5.198, outside the advisory's vulnerable range. The advisory affects only MessagePack's LZ4 decompression path. We do not use MessagePackFormatter anywhere - all StreamJsonRpc sites use SystemTextJsonFormatter - and our JSON-RPC transports are local UDS under the user's home directory, so the underlying vulnerability was not reachable. This change is warning hygiene. Fixes #18153 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Pin MessagePack to 2.5.302 to fully clear GHSA-hv8m-jj95-wg3x StreamJsonRpc 2.25.25 still declares a transitive dep on MessagePack 2.5.198, which is inside the advisory's vulnerable range (< 2.5.302). Add a direct PackageReference on MessagePack to Aspire.Hosting so consumers (including generated AppHosts from 'aspire new aspire-starter') restore the patched version, and NU1903 is no longer emitted. This can be removed once StreamJsonRpc ships a release that depends on MessagePack >= 2.5.302. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Revert StreamJsonRpc bump; keep MessagePack 2.5.302 pin StreamJsonRpc 2.25.25 ships analyzers built against Roslyn 4.14, which breaks template tests that build generated AppHosts with the .NET 8 SDK (CSC error CS9057). The MessagePack 2.5.302 direct pin in Aspire.Hosting already overrides StreamJsonRpc 2.22.23's transitive MessagePack 2.5.192 in consumer projects, so the GHSA-hv8m-jj95-wg3x warning is silenced without needing the StreamJsonRpc bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump StreamJsonRpc to 2.25.28 and drop MessagePack pin StreamJsonRpc 2.25.28 brings MessagePack 2.5.302 transitively, which is above the GHSA-hv8m-jj95-wg3x / CVE-2026-48109 vulnerable range. This lets us drop the direct MessagePack PackageReference (and PackageVersion) we added earlier as a workaround. StreamJsonRpc 2.25.x ships an analyzer built against Roslyn 4.14, which is newer than the Roslyn 4.11 in the .NET 8 SDK used by template tests to build generated AppHost projects (would trigger CSC error CS9057). We don't use the StreamJsonRpc analyzers anywhere in this assembly, so ExcludeAssets="analyzers" skips them. NuGet bakes the exclusion into the Aspire.Hosting nuspec so downstream consumers (AppHost projects) also skip the analyzer transitively. See microsoft/vs-streamjsonrpc#1459 for the upstream MessagePack bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Strip StreamJsonRpc analyzer from consumer AppHost builds ExcludeAssets in Aspire.Hosting alone is not enough: the .NET 8 SDK discovers analyzer DLLs in the NuGet cache by convention regardless of the project.assets.json exclude flags, and StreamJsonRpc.Analyzers.dll (Roslyn 4.14) fails to load under SDK 8's Roslyn 4.11 with CS9057. Add a target in Aspire.Hosting.AppHost.targets that runs before CoreCompile and removes any Analyzer item whose path contains 'StreamJsonRpc.Analyzers'. Aspire doesn't depend on any of the StreamJsonRpc analyzer diagnostics, so dropping them is safe. Verified locally: building a net8.0 AppHost with the .NET 8 SDK (Roslyn 4.11) no longer hits CS9057. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Move StreamJsonRpc analyzer strip to Aspire.Hosting buildTransitive The Aspire.Hosting.AppHost targets file only reaches direct AppHost consumers — but Aspire.Hosting.Testing also pulls StreamJsonRpc in transitively, and the test project (.aspire_xunitTests.csproj) hit the same CS9057 under .NET 8 SDK. Move the analyzer-strip target into Aspire.Hosting's buildTransitive/Aspire.Hosting.targets so every consumer of Aspire.Hosting (AppHost projects, test projects, etc.) automatically drops the StreamJsonRpc analyzer. Verified locally: a net8.0 test project that references Aspire.Hosting.Testing builds cleanly under the .NET 8 SDK. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Simplify StreamJsonRpc analyzer-strip condition using %(Filename) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump StreamJsonRpc to 2.25.29; drop analyzer-strip workaround StreamJsonRpc 2.25.29 ships analyzers compiled against an older Roslyn that is compatible with the .NET 8 SDK (vs-streamjsonrpc#1463 / #1399), so the buildTransitive analyzer-strip target and the ExcludeAssets flag on the PackageReference are no longer needed. Mirrors the final state of #18155 on main. 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>
The npm ESRP publish validation previously allowed multiple owner aliases as long as at least one was a required release owner. Restrict owners to a single alias (matching the existing single-approver rule) so ownership of the @microsoft/aspire-cli package maps to one accountable alias. - Add Assert-SingleNpmReleaseAlias for owners before the required-owner check, mirrored in both validate-npm-release-aliases.ps1 and the inline helpers in release-publish-nuget.yml. - Change NpmPublishOwners default from 'joperezr,ankj' to 'joperezr' (the old multi-owner default would now fail validation) and update the param displayName/spec doc to describe the single-owner rule. - Update Infrastructure.Tests to cover multi-owner rejection and the new default. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…tandalone dashboard (#18221) * Make npm package README TypeScript-only and document standalone dashboard Port of #18220 to release/13.4. - Remove the C# AppHost example so the npm README is TypeScript-only. - Refresh the TypeScript example to the current ts-starter template (apphost.mts importing ./.aspire/modules/aspire.mjs), fixing the stale apphost.ts / aspire.js references that no longer match the template. - Add a Postgres + Redis backing-services example with an `aspire add` note for the postgresql and redis integrations. - Add a Standalone dashboard section documenting `aspire dashboard run`. - Update NpmCliPackageTests to assert the TypeScript-only README content. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Restore Install heading dropped from npm README Code review found the install instructions were orphaned under the 'Add backing services' subsection after the C# example removal. Restore the '## Install' heading so install steps render as their own section. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Copilot's findings
Files not reviewed (2)
- src/Aspire.Cli/Resources/AgentCommandStrings.Designer.cs: Generated file
- src/Aspire.Cli/Resources/UpdateCommandStrings.Designer.cs: Generated file
- Files reviewed: 130/133 changed files
- Comments generated: 1
|
|
||
| await app.StopAsync(); | ||
| } | ||
| [Fact] |
Contributor
There was a problem hiding this comment.
Copilot's findings
Files not reviewed (2)
- src/Aspire.Cli/Resources/AgentCommandStrings.Designer.cs: Generated file
- src/Aspire.Cli/Resources/UpdateCommandStrings.Designer.cs: Generated file
- Files reviewed: 130/133 changed files
- Comments generated: 0 new
This was referenced Jun 17, 2026
Open
Updated MongoDB.Driver version from 3.8.1 to 3.9.0 and removed pinned versions for SharpCompress and Snappier. Co-authored-by: Benjamin Krämer <benjamin.kraemer@alien-scripts.de>
… codegen binding (#18160) Polyglot (TypeScript/Python/Java/Go/Rust) AppHost code generation silently fails ("No code generator found for language: ...") when the installed CLI and the AppHost's SDK skew in version. The CLI's bundled apphost server force-shares Aspire.TypeSystem from its default ALC, but the SDK-side codegen assemblies carry a strong-named reference to a different Aspire.TypeSystem version. The CLR only satisfies a strong-named reference when the loaded copy's AssemblyVersion is >= the requested version, so a floating per-build AssemblyVersion makes the bind fail, Assembly.GetTypes() throws ReflectionTypeLoadException, and every generator is dropped. Freeze the strong-name AssemblyVersion at the fixed constant 13.4.5.0, decoupled from the build and carried forward to all later releases so every later stable and servicing release bundles the same value. 13.4.5.0 is chosen because it matches the AssemblyVersion of the latest already-shipped stable (13.4.5, whose AssemblyVersion floated to 13.4.5.0), so the already-released 13.4.5 CLI and every post-freeze CLI/SDK carry the identical constant and never skew. Only AssemblyVersion is frozen; FileVersion/InformationalVersion/PackageVersion stay build-derived so diagnostics keep real identities. Document the now-intentional shared-from-bundle binding in IntegrationLoadContext and the version-ordered warning in AssemblyLoader. Binary-incompatible changes to the shared contract are caught by the repository's standard public API compatibility tracking (the checked-in api/Aspire.TypeSystem.cs reference surface and package baseline validation), which forces a deliberate AssemblyVersion bump instead of silently reintroducing the binding failure. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Copilot's findings
Files not reviewed (2)
- src/Aspire.Cli/Resources/AgentCommandStrings.Designer.cs: Generated file
- src/Aspire.Cli/Resources/UpdateCommandStrings.Designer.cs: Generated file
- Files reviewed: 133/136 changed files
- Comments generated: 0 new
4 tasks
Member
|
Closing in favor of #18302, which forward-ports release/13.4 into main with hand-resolved conflicts on a dedicated branch (off release/13.4) rather than committing resolutions to the release branch. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR merges the
release/13.4branch back tomainafter the v13.4.1 release.Checklist
Created automatically by the release workflow.