Comparing changes

…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 <[email protected]> * 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 <[email protected]> Co-authored-by: Copilot <[email protected]>

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 <[email protected]> Co-authored-by: Copilot <[email protected]>

…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 <[email protected]> * 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 <[email protected]> * 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 <[email protected]> * 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 <[email protected]> * 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 <[email protected]> * 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 <[email protected]> * Simplify StreamJsonRpc analyzer-strip condition using %(Filename) Co-authored-by: Copilot <[email protected]> * 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 <[email protected]> --------- Co-authored-by: Mitch Denny <[email protected]> Co-authored-by: Copilot <[email protected]>

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 <[email protected]>

…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 <[email protected]> * 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 <[email protected]> --------- Co-authored-by: Copilot <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on Jun 16, 2026

This comparison is taking too long to generate.

Uh oh!