[Karol Zadora-Przylecki (karolz-ms)]

Description

DotnetProjectResource services currently perform separate implicit builds when they start. When several services reference the same projects, those builds can write to shared bin and obj directories concurrently, causing nondeterministic failures. This change gives Project v2 one coordinated initial build phase so every service starts from a consistent set of outputs.

Coordinated build

Compatible .csproj resources are collected into generated MSBuild traversal projects under the AppHost's intermediate output (Aspire:Store:Path/.aspire/build). Projects within a traversal build can run in parallel and MSBuild deduplicates shared references; build groups run serially because different SDK selections, configurations, or build environments can still target overlapping outputs.

Resources using WithBuildEnvironment(...) receive serialized direct builds. This keeps project-specific MSBuild inputs isolated while allowing runtime-only values—including service-discovery and connection-string variables from WithReference(...)—to remain outside the build grouping decision.

File-based .cs applications cannot participate in traversal projects and continue using dotnet run --file ... --no-cache. In mixed applications, they wait for the coordinated build because #:project references may share outputs with project-based resources.

Starting the built output

After the coordinated build, Aspire resolves each project's RunCommand, RunArguments, and working directory from the same build context and launches that output directly. This avoids a later dotnet run evaluation using runtime environment variables, selecting a different output, or starting another build.

Missing project files remain on the ordinary dotnet run --project <path> path so the resulting SDK error is associated with the affected resource rather than failing the shared build. Coordinated-build failures retain their logs and block both normal and forced resource starts.

IDE and F5 launches

The substantial changes in extension/src/debugger/languages/dotnet.ts teach the VS Code extension about outputs produced by an external coordinated build. The extension now honors the AppHost configuration, build environment, SDK-discovery working directory, and build-suppression state instead of independently selecting or rebuilding the default Debug output and recreating the original race.

The extension also resolves RunCommand and RunArguments in that same context. For file-based applications, Configuration is supplied as a global MSBuild property so an in-source #:property Configuration=... directive cannot redirect the IDE to a different output.

The Hosting launch metadata and pipeline APIs are generalized so Aspire.Hosting.Dotnet can carry this contract to IDEs without depending on production InternalsVisibleTo access or duplicating core launch behavior.

Generated artifact safety

Traversal projects need stable paths under the AppHost's intermediate output and can be shared by concurrent AppHost processes. They are therefore content-addressed, published atomically, protected by held-file leases, and removed only after they are no longer in use. Filesystem path canonicalization prevents casing and symlink aliases from creating conflicting build identities.

Because these generated files live under Aspire:Store:Path/.aspire/build instead of the source tree, project templates and aspire init do not need to modify .gitignore.

The shared held-file lease primitive is also used by bundle-version cleanup, allowing both cleanup paths to conservatively retain data when lease state cannot be determined.

User-facing usage

C# AppHost

var api = builder.AddDotnetProject("apiservice", "../DotnetProject.ApiService");

builder.AddDotnetProject("workerservice", "../DotnetProject.WorkerService")
    .WithReference(api)
    .WithBuildEnvironment("BUILD_FLAVOR", "custom");

builder.AddDotnetProject("worker", "../worker/worker.cs")
    .WithReference(api);

TypeScript AppHost

const api = await builder.addDotnetProject(
    "apiservice",
    "../DotnetProject.ApiService");

await builder
    .addDotnetProject("workerservice", "../DotnetProject.WorkerService")
    .withReference(api)
    .withBuildEnvironment("BUILD_FLAVOR", "custom");

await builder
    .addDotnetProject("worker", "../worker/worker.cs")
    .withReference(api);

WithBuildEnvironment(...) is intended for values that affect MSBuild evaluation. These values are not automatically added to the launched process; use WithEnvironment(...) separately when the same value is also required at runtime. Build environments should not contain secrets because their values may appear in build diagnostics.

The playground no longer needs manual WaitFor(...) chains to serialize service builds.

Validation

• ./build.sh --build --pack /p:SkipNativeBuild=true
• Aspire.Hosting.Dotnet.Tests: 96 passed
• Hosting pipeline and reference tests: 128 passed
• PathNormalizerTests: 7 passed
• VS Code extension unit tests: 2,632 passed, 6 pending
• VS Code extension coordinated-build E2E on Linux and Windows: 2 passed

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No

Fixes

#19037

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19678

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

Adds a run-only build coordinator that builds .NET project resources together before startup.

Changes:

• Generates and builds a content-addressed .slnx.
• Launches projects with --no-build and gates mixed file-based apps.
• Adds tests, documentation, and simplified playground examples.

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
Directory.Packages.props	Adds SolutionPersistence version.
src/Aspire.Hosting.Dotnet/Aspire.Hosting.Dotnet.csproj	References SolutionPersistence.
src/Aspire.Hosting.Dotnet/DotnetProjectBuildCoordinator.cs	Coordinates build lifecycle.
src/Aspire.Hosting.Dotnet/DotnetProjectBuildResource.cs	Generates and builds the solution.
src/Aspire.Hosting.Dotnet/DotnetProjectHostingExtensions.cs	Wires build coordination into projects.
src/Aspire.Hosting.Dotnet/DotnetProjectMetadata.cs	Tracks build suppression.
src/Aspire.Hosting.Dotnet/README.md	Documents coordinated builds.
tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectBuildCoordinatorTests.cs	Tests coordination and failures.
tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectResourceTests.cs	Updates launch-argument expectations.
tests/Aspire.Hosting.Dotnet.Tests/Snapshots/DotnetProjectBuildCoordinatorTests.GeneratedSolutionContainsOnlyUniqueProjectsInModelOrder.verified.slnx	Verifies generated solution content.
playground/DotnetProject/DotnetProject.AppHost/AppHost.cs	Removes manual build ordering.
playground/DotnetProject/TypeScriptAppHost/apphost.mts	Removes TypeScript wait chains.
docs/plans/project-v2-csharpprogram-watch.md	Records completed build design.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

Pull request overview

Copilot reviewed 28 out of 28 changed files in this pull request and generated 2 comments.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Karol Zadora-Przylecki (karolz-ms)]

Code review — 8 findings

Reviewed at head e569c99. The two earlier Copilot threads (SuppressBuild not flowing to IDE launches, OS-based case-sensitivity in AddProject) are resolved by 4393790 and are not repeated here.

Note: the GitHub review-write API isn't reachable from this environment, so these are posted as one comment instead of inline review comments. Each finding cites file:line at the PR head.

---

1. New E2E spec has no CI shard — the shard-matrix guard test will fail and the spec never runs

extension/src/test-e2e/coordinatedBuild.e2e.test.ts is added, but .github/workflows/extension-e2e-tests.yml has no matching matrix row (34 rows covering 20 specs, none for coordinatedBuild).

extension/src/test/e2eShardMatrix.test.ts:152 (runs exactly the set of E2E specs in the CI matrix) asserts "The E2E workflow matrix must exactly match the .e2e.test.ts files under src/test-e2e", so this is a deterministic unit-test failure — and the new E2E coverage would never execute in CI even if that test were relaxed.

Fix: add a matrix row with spec: out/test-e2e/test-e2e/coordinatedBuild.e2e.test.js (and a shardName, e.g. coordinated-build).

---

2. suppress_build now applies to every classic AddProject<T> resource, turning a self-healing path into a hard failure

src/Aspire.Hosting/ApplicationModel/ProjectLaunchConfigurationFactory.cs:35 now emits SuppressBuild = projectMetadata.SuppressBuild for all project resources. SDK-generated Projects.* metadata returns SuppressBuild => true (src/Aspire.Hosting.AppHost/build/Aspire.Hosting.AppHost.in.targets:86) — confirmed by this PR's own new assertion Assert.True(launchConfiguration.SuppressBuild) for AddProject<Projects.ServiceA> at tests/Aspire.Hosting.Tests/DebugSupportExtensionsTests.cs:112.

Downstream in extension/src/debugger/languages/dotnet.ts:

• shouldBuildProject (line 798) becomes false for every classic project, so launchOptions.forceBuild is also ignored on that path.
• The missing-output branch at line 941-943 now throws instead of building.

Net effect: for every existing Aspire app, a resource whose bin/ output is missing (clean, pruned artifacts, Directory.Build.props output-path change, first F5 after a git clean) used to be rebuilt automatically at line 946 and now aborts the launch. The PR description scopes this change to Project v2, so this looks unintended.

Fix: keep the build-on-missing-output fallback for resources that aren't part of a coordinated build — e.g. gate the throw on the resource actually participating in __dotnet-project-build, rather than on suppress_build alone.

The comments at dotnet.ts:794-795 ("The hosting integration currently suppresses only coordinated .csproj builds") no longer describe what the code does, which reinforces that this broadening was accidental.

---

3. coordinatedBuildOutputMissing message is inaccurate for classic projects

extension/src/loc/strings.ts:57 / extension/package.nls.json:113:

"The coordinated build output {1} for project {0} does not exist. Aspire will not rebuild the project independently."

AddProject<Projects.X> resources never participate in a coordinated build — their output comes from the AppHost's own build — so users hitting this (see finding 2) will go looking for a coordinated build that doesn't exist. If finding 2 is fixed by scoping the throw, this string becomes correct; otherwise the wording needs to cover both producers.

---

4. Test coverage regression: the only non-suppressed dotnet run fallback test was repurposed rather than added

extension/src/test/dotnetDebugger.test.ts:2429 renames uses dotnet CLI when project runtimeconfig has no runnable framework to coordinated project uses configured dotnet CLI fallback without rebuilding, changing the asserted args from ['run','--project',p,'--no-launch-profile'] to the --no-build --configuration Release variant.

No remaining test asserts the non-suppressed argument shape, but that path is still reachable:

• AddProject(string path) → ProjectMetadata.SuppressBuild => false
• Azure Functions → SuppressBuild => false (src/Aspire.Hosting.Azure.Functions/AzureFunctionsProjectResourceExtensions.cs:414)
• Older AppHosts that don't send suppress_build at all

Fix: restore the original test and add the coordinated variant alongside it, so both branches of createDotNetRunArguments stay covered.

---

5. Rebuild command and coordinated build can target different configurations

src/Aspire.Hosting/ProjectResourceBuilderExtensions.cs:1074 runs the rebuilder as dotnet build <project> with no --configuration, while AddDotnetProject now launches with --no-build --configuration <AppHost configuration> (src/Aspire.Hosting.Dotnet/DotnetProjectHostingExtensions.cs:155-164).

With a Release AppHost, the dashboard Rebuild command writes bin/Debug/... while the restarted resource keeps launching the stale bin/Release/... binary — the rebuild silently has no effect and the user sees old code. This mismatch pre-dates the PR for classic projects, but it becomes user-visible now that --no-build is passed.

Fix: pass the same effective configuration to the rebuilder args (ProjectLaunchDefaultsAnnotation.BuildConfiguration, which :508-510 already computes).

---

6. PathNormalizer.ResolveToFilesystemPath now fully enumerates every ancestor directory, on every platform

src/Shared/PathNormalizer.cs:85 replaced OS-filtered lookups with Directory.EnumerateFileSystemEntries(current) for every segment of the path, and the method is now active on Linux/macOS where it previously short-circuited.

It runs on the CLI AppHost resolution path (src/Aspire.Cli/Projects/ProjectLocator.cs:998, feeding the backchannel socket hash) and once per project in DotnetProjectBuildResource.AddProject. For a repo rooted under a large or network-mounted directory (e.g. a src/ with thousands of entries, or a mapped/\\wsl$ share), this turns a handful of stat calls into a full listing of every ancestor.

Fix: probe with a filtered lookup first (Directory.GetFileSystemEntries(current, segment)), and fall back to the full enumeration only when that returns zero or more than one candidate — the ambiguity handling at :101-104 is the only part that actually needs the complete listing.

---

7. WriteSolutionCoreAsync's finally can mask the real failure

src/Aspire.Hosting.Dotnet/DotnetProjectBuildResource.cs:125-131 — the cleanup File.Delete(temporaryPath) is unguarded. On Windows an AV scanner or indexer holding the temp file makes File.Delete throw, which replaces the original write/move exception and fails the whole __dotnet-project-build resource with a misleading error. There's also a File.Exists → File.Delete TOCTOU window.

Fix: wrap the delete in try { ... } catch (IOException) { } / catch (UnauthorizedAccessException) { } so cleanup is best-effort and never supersedes the real exception.

---

8. Generated .slnx files accumulate in a directory users commit

SolutionDirectory = Path.Combine(workingDirectory, ".aspire", "build") (DotnetProjectBuildResource.cs:24) with a content-addressed projects.<hash>.slnx (:104). Every change to the project set (adding, removing, or renaming a DotnetProjectResource) leaves another file behind, and nothing ever prunes them.

.aspire/ is a directory users normally commit — it holds settings.json — and the Aspire templates don't ship a .gitignore covering it, so these build artifacts will show up in git status and get committed. Consider pruning stale projects.*.slnx on write, or writing under an ignored/temp location.

[Karol Zadora-Przylecki (karolz-ms)]

Replying to the eight findings in #19678 (comment). Changes are in 904983258b.

1. New E2E spec has no CI shard

Fixed. Added the blocking Linux coordinated-build matrix row for coordinatedBuild.e2e.test.js. The shard-matrix tests and the full extension unit suite pass.

2. suppress_build applies to classic AddProject<T> resources

No behavior change was made because this finding is invalid. SuppressBuild is the generic contract that output was produced by another producer; SDK-generated classic Projects.* metadata intentionally sets it, and process-mode launch already honors it with --no-build. Normal first launch builds the AppHost project references before the IDE launch. Scoping this to __dotnet-project-build would break classic and external producers and would require coordinator provenance that is not part of the launch payload.

3. coordinatedBuildOutputMissing is inaccurate for classic projects

Fixed. The diagnostic is now prebuiltProjectOutputMissing and says that the expected prebuilt output is missing and building is suppressed. The nearby comment now explicitly covers both classic AppHost builds and coordinated builds; localization sources and XLF were regenerated.

4. Ordinary non-suppressed dotnet run fallback coverage was replaced

Fixed. Restored the ordinary project fallback test for dotnet run --project ... --no-launch-profile and retained the coordinated variant that verifies --no-build --configuration Release.

5. Rebuild and coordinated launch can use different configurations

Fixed. The hidden rebuilder now appends --configuration from ProjectLaunchDefaultsAnnotation.BuildConfiguration when present. Added Release coverage for both classic AddProject<T> and Project v2 AddDotnetProject resources.

6. ResolveToFilesystemPath enumerates ancestor directories

No change was made because this finding is not sufficiently valid as a regression. Enumeration is lazy and stops on an exact match, and these calls occur during startup/project discovery rather than on a hot path. The suggested filtered search still enumerates on Unix and can interpret legal POSIX */? filename characters as patterns, risking the volume-aware correctness fix without measured evidence of a startup regression.

7. WriteSolutionCoreAsync cleanup can mask the real failure

Fixed. Temporary-file deletion is now best-effort, catches and debug-logs IO/access failures, and cannot replace the primary write/move/cancellation exception. Stale crash-left temporary files are also pruned conservatively.

8. Generated .slnx files accumulate under .aspire/build

Fixed, with the source-control premise narrowed: .aspire/ was already ignored by this repo and polyglot starters, but C# template/init parity was missing. Added .aspire/ to the C# templates and both init paths, plus a non-overwriting .aspire/build/.gitignore for existing repos. Generated solutions now use per-hash AppHost-lifetime held-file leases under a global lock; recognized files are pruned only after 24 hours continuously unleased, and unknown lease/state data is retained. This keeps concurrent AppHosts safe and handles crash leftovers without PID-based ownership.

[Copilot]

Pull request overview

Copilot reviewed 51 out of 51 changed files in this pull request and generated 2 comments.

Suppressed comments (1)

src/Aspire.Hosting/ApplicationModel/ExecutableLaunchConfiguration.cs:134

• BuildConfiguration is a new public member on ProjectLaunchConfiguration (and SuppressBuild below is another), but the PR checklist says no public API was added. Update the PR metadata and route these additions through the required API review before merging.

    [JsonPropertyName("build_configuration")]
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingNull)]
    public string? BuildConfiguration { get; set; }

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Karol Zadora-Przylecki (karolz-ms)]

Code review of the coordinated Project v2 build. 4 issues found:

• Correctness / behavior change (2): the coordinated .slnx build injects MSBuild solution global properties that individual project builds never set; suppress_build is now emitted for every classic AddProject resource, which removes the VS Code extension's recovery build for the existing v1 user base.
• Performance (1): PathNormalizer.ResolveToFilesystemPath regressed from a filtered, Windows-only lookup to a full directory enumeration per path segment on all platforms.
• Test reliability (1): two new tests depend on POSIX permission enforcement and fail when the test process runs as root (anchored on both affected files).

Already-resolved threads (IDE suppress-build, case-sensitivity dedup, symlink dedup, public API checklist) were excluded.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Karol Zadora-Przylecki (karolz-ms)]

Replying to the suppressed finding in Copilot review 5117291723:

The exception contract is inaccurate: ArgumentException.ThrowIfNullOrEmpty(stepName) throws ArgumentNullException when stepName is null, but the ArgumentNullException documentation lists only pipeline and action.

Verdict: valid. Fixed in 7baff9f. The WithFinalAction XML documentation now includes stepName under ArgumentNullException and reserves ArgumentException for an empty stepName, matching the runtime behavior. No runtime or public API shape changed.

[Copilot]

🔵 Needs a closer look

The large cross-component change introduces build orchestration, IDE integration, and filesystem concurrency behavior that warrants final human review.

Review details

Files not reviewed (1)

• src/Aspire.Cli/Resources/TemplatingStrings.Designer.cs: Generated file

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/Aspire.Hosting.Dotnet/DotnetProjectHostingExtensions.cs:338

• The PR description says coordinated file apps continue with dotnet run --file ... --no-cache, but this path launches them with --no-build; the new README and coordinator test also assert --no-build. Please update the PR description to match the implemented behavior, since suppressing this second build is essential to the race fix.

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

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

🟡 Changes recommended

The claimed atomic, symlink-safe .gitignore update remains a direct symlink-following write.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 68/69 changed files
• Comments generated: 1
• Review effort level: Balanced

[Copilot]

🔵 Needs a closer look

VS Code incorrectly rejects valid custom external run commands when their project has no TargetPath artifact.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

extension/src/debugger/languages/dotnet.ts:1335

• External-build launches reject a missing TargetPath before honoring the resolved RunCommand. A valid project can set RunCommand to an unrelated launcher and intentionally produce no target artifact; the DCP path launches that command directly, but F5 fails here with “prebuilt output missing.” Only require TargetPath/the apphost when the resolved command actually uses the project output (for example, when canDebugResolvedProjectRunCommand returns true); otherwise proceed with the custom command.

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

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Karol Zadora-Przylecki (karolz-ms)]

PR Testing Report

PR Information

• PR Number: Project v2 build #19678
• Title: Project v2 build
• Head Commit: 95207f804a14de76146ee5273e99eca70a708e98
• Tested At: 2026-09-05T00:35:00Z
• Execution Target: Local Windows temp directory

Artifact Version Verification

• Expected Commit: 95207f804a14de76146ee5273e99eca70a708e98
• Installed CLI: 13.6.0-pr.19678.g95207f80
• Source Checkout: 95207f804a14de76146ee5273e99eca70a708e98
• Status: Verified

Changes Analyzed

Change Categories

• CLI changes
• Hosting and application-model changes
• VS Code extension changes
• GitHub Actions workflow changes
• Unit and E2E test changes
• Dashboard UI changes
• Azure DevOps pipeline changes

The current head implements coordinated builds for path-based .NET project resources,
build-only environment handling, launch-property resolution from externally built outputs,
and corresponding VS Code debugger support. The extension E2E workflow adds Linux and Windows
coordinated-build shards.

The PR description is stale for .gitignore hardening. Final commit 70c89ce5 removed the
atomic/symlink-aware implementation and template ignore files while leaving one CLI test expecting
the old behavior.

Test Scenarios Executed

Scenario 1: PR artifact identity

Objective: Verify that all product scenarios use the current PR artifact.

Coverage Type: Artifact validation

Status: Passed

Evidence:

• install.log
• version.txt

Observations:

• The installer selected workflow run 33928693484.
• The installed version was 13.6.0-pr.19678.g70c89ce5, matching the PR head.
• After the test correction was pushed, the installer selected workflow run 33931645917.
• The refreshed version was 13.6.0-pr.19678.g95207f80, matching the updated PR head.

---

Scenario 2: Shared project graph coordinated build

Objective: Verify that two services sharing a project reference use one coordinated build,
wait for it, and then launch from the produced outputs.

Coverage Type: Happy path

Status: Passed

Steps:

1. Created a fresh C# AppHost with ServiceA and ServiceB.
2. Both services referenced SharedLib.
3. Added an MSBuild observation target to count compilation of SharedLib.
4. Started the AppHost with the PR CLI and waited for both resources to be up.
5. Captured hidden resource states and resource logs.

Evidence:

• scenario-shared\SharedBuild\start.log
• scenario-shared\SharedBuild\describe.json
• scenario-shared\SharedBuild\logs.json
• scenario-shared\SharedBuild\assertions.json

Observations:

• One hidden __dotnet-project-build resource completed with exit code 0.
• Both services explicitly waited for that build resource.
• SharedLib recorded exactly one build.
• Both services reached Running and logged the expected shared value.

---

Scenario 3: Build-environment isolation and direct launch

Objective: Verify that WithBuildEnvironment(...) affects MSBuild evaluation, runtime-only
environment values do not redirect output, and the resource launches the selected output.

Coverage Type: Happy path and boundary

Status: Passed

Steps:

1. Created a project whose output path is bin\custom when BUILD_FLAVOR=custom.
2. Added a conflicting bin\wrong condition for the runtime-only RUNTIME_ONLY value.
3. Configured build-time BUILD_FLAVOR=custom and runtime values
   BUILD_FLAVOR=runtime, RUNTIME_ONLY=runtime-value.
4. Started the AppHost and captured build and process logs.

Evidence:

• scenario-env\EnvBuild\start.log
• scenario-env\EnvBuild\describe.json
• scenario-env\EnvBuild\logs.json
• scenario-env\EnvBuild\assertions.json

Observations:

• The build environment contained BUILD_FLAVOR=custom and no RUNTIME_ONLY.
• The output was Worker\bin\custom\net10.0\Worker.dll.
• Worker\bin\wrong was not created.
• The launched process received the runtime values and reached Running.

---

Scenario 4: Mixed project and file-based app

Objective: Verify that a file-based .cs app with a shared project reference is serialized
after the project traversal build and launched with --no-build.

Coverage Type: Happy path and boundary

Status: Passed

Evidence:

• scenario-mixed\MixedBuild\start.log
• scenario-mixed\MixedBuild\describe.json
• scenario-mixed\MixedBuild\logs.json

Observations:

• The traversal build completed first.
• The file-app direct build waited for the traversal build.
• Both resources waited for both coordinated build groups.
• The file app launched as dotnet run --file ... --no-build.
• Both resources reached Running and consumed the shared project output.

---

Scenario 5: Coordinated-build failure safety

Objective: Verify that a deterministic compile failure retains build diagnostics and blocks
both automatic and explicit resource starts.

Coverage Type: Unhappy path

Status: Passed

Expected Outcome: The build fails safely, both project resources remain failed, logs identify
the build resource, and an explicit start returns a non-zero exit code.

Evidence:

• scenario-failure\FailureBuild\logs-before.json
• scenario-failure\FailureBuild\logs-after.json
• scenario-failure\FailureBuild\describe-before.json
• scenario-failure\FailureBuild\describe-after.json
• scenario-failure\FailureBuild\force-start.log
• scenario-failure\FailureBuild\command-exits.json

Observations:

• The hidden build resource finished with exit code 1.
• The compiler error and Build FAILED output remained available.
• good-service and broken-service both stayed FailedToStart.
• Explicitly starting good-service returned exit code 16 and identified
  __dotnet-project-build as the source of the failure.

---

Scenario 6: aspire init existing-ignore behavior

Objective: Verify the behavior of the final PR head rather than the stale PR description.

Coverage Type: Compatibility and idempotency

Status: Passed for current-head behavior

Evidence:

• scenario-init\ExistingRepo\init-first.log
• scenario-init\ExistingRepo\init-second.log
• scenario-init\ExistingRepo\assertions.json
• scenario-init-project\ExistingRepo\init-first.log
• scenario-init-project\ExistingRepo\init-second.log
• scenario-init-project\ExistingRepo\assertions.json

Observations:

• Single-file and project-mode initialization preserved the existing .gitignore content.
• Re-running initialization was idempotent.
• Neither mode added .aspire/, consistent with the behavior remaining at final head.

Initial Issue and Recheck:

• The PR retained
  NewCommandWithExplicitCSharpEmptyTemplateCreatesCSharpAppHostAndGitIgnore, but final commit
  70c89ce5 deleted the template .gitignore.
• The resulting deterministic FileNotFoundException failed Aspire.Cli.Tests on Windows,
  Linux, and macOS.
• Commit 95207f804a restored the test's original name and removed the obsolete .gitignore
  assertion.
• The corrected test passed locally, and the complete Aspire.Cli.Tests jobs passed on Windows,
  Linux, and macOS in run 33931645917.

---

Scenario 7: VS Code extension validation

Objective: Verify the extension source, changed debugger tests, and coordinated-build behavior
in a real Extension Host.

Coverage Type: Build, unit, and E2E

Status: Passed for changed coordinated-build behavior; unrelated environment failures remain
in the broad unit run.

Evidence:

• extension-build.log
• extension-unit-tests.log
• extension-unit-tests-clean-env.log
• extension-coordinated-build-e2e.log
• extension-apphost-lifecycle-e2e.log

Observations:

• extension\build.ps1 completed successfully and built the extension and Aspire CLI.
• The initial broad unit run reported 2,844 passing, 11 pending, and 11 failing.
• Removing inherited malformed GIT_CONFIG_* variables improved the result to
  2,848 passing, 11 pending, and 7 failing.
• The remaining failures were outside the PR-changed debugger area and were caused by local
  Windows symlink privilege errors, a deep-path ENAMETOOLONG error, and one filesystem
  ctimeMs mismatch.
• The focused coordinated-build Extension Host run passed 3/3:
  • build environment and Release output were honored without rebuilding;
  • custom run command, arguments, and working directory were honored without rebuilding;
  • file-app configuration overrode an in-source conflicting configuration.
• The broad local appHostLifecycleTools shard was stopped after two unrelated failures and a
  prolonged hang. It was not used to evaluate the coordinated-build change.
• The updated PR CI reran the Windows apphost-lifecycle-tools shard successfully.
• The updated PR CI also passed the Windows extension unit-test job.

---

Scenario 8: GitHub Actions workflow validation

Objective: Verify the changed extension E2E matrix and its actual PR jobs.

Coverage Type: CI infrastructure

Status: Passed

Evidence:

• infrastructure-tests.log
• Initial workflow run: https://github.com/microsoft/aspire/actions/runs/33928693484
• Updated workflow run: https://github.com/microsoft/aspire/actions/runs/33931645917

Observations:

• .github\workflows\extension-e2e-tests.yml parsed successfully.
• git diff --check found no formatting errors.
• ExtensionE2eWorkflowTests and TestTriggerMapTests passed 68/68.
• The matrix grew from 39 to 41 entries.
• No baseline shard entry was removed.
• Exactly two coordinated-build entries were present.
• The actual PR jobs passed:
  • Linux coordinated build:
    https://github.com/microsoft/aspire/actions/runs/33931645917/job/101215264225
  • Windows coordinated build:
    https://github.com/microsoft/aspire/actions/runs/33931645917/job/101215264305

CI Recheck Classification

Job	Result	Classification
Aspire.Cli.Tests Windows	Passed	Initial PR-caused assertion failure resolved by 95207f804a
Aspire.Cli.Tests Linux	Passed	Initial PR-caused assertion failure resolved by 95207f804a
Aspire.Cli.Tests macOS	Passed	Initial PR-caused assertion failure resolved by 95207f804a
VS Code E2E Windows apphost-lifecycle-tools	Passed	Initial timing failure did not reproduce
Aspire.Hosting.Azure.Kubernetes.Tests Windows	Passed	Initial timeout did not reproduce
VS Code extension unit tests Windows	Passed	Local cache-test failures were environment-specific
VS Code E2E Windows dynamic-debug-configuration	Failed	New unrelated teardown-only file-lock failure

VS Code lifecycle failure evidence

• Current run passed 7/8 tests.
• The only failure timed out after 10 seconds waiting for
  .e2e-cli-wrappers\run-aspire-cli-timeout\timeout-child.pid.
• The same shard passed 8/8 in prior run 33916911179 at PR head 7baff9fa.
• The failed test and its runAspireCli path did not change between 7baff9fa and 70c89ce5.
• The PR's new Linux and Windows coordinated-build shards both passed.
• The updated run passed the Windows lifecycle shard:
  https://github.com/microsoft/aspire/actions/runs/33931645917/job/101215264080.

Kubernetes failure evidence

• The only failed test was
  DestroyPipelineUsesPersistedAksResourceIdWhenScopeIsAbsent.
• It failed with System.TimeoutException.
• The same Windows job passed in prior run 33916911179.
• No Azure Kubernetes or shared pipeline file changed between PR heads 7baff9fa and 70c89ce5.
• The updated run passed the Windows Kubernetes job:
  https://github.com/microsoft/aspire/actions/runs/33931645917/job/101213710250.

New dynamic-debug teardown failure

• The actual test
  re-resolves the selected AppHost by dynamic configuration name in duplicate-alias workspaces
  passed.
• Its after each cleanup failed with EBUSY while removing
  .e2e-dynamic-debug\second.
• The same Windows shard passed in both earlier PR runs 33916911179 and 33928693484.
• The only change in 95207f804a was the CLI unit-test correction, so this cleanup lock is unrelated
  to the PR fix.

Summary

Scenario	Status	Notes
Artifact identity	Passed	Refreshed PR CLI matched 95207f804a
Shared coordinated build	Passed	Shared dependency built once
Build environment and launch output	Passed	Build/runtime values remained isolated
Mixed project/file app	Passed	Builds serialized; file app used --no-build
Build failure safety	Passed	Logs retained; forced start blocked
Init behavior	Passed with stale-description caveat	Current head preserves existing ignore content
Extension build and coordinated E2E	Passed	Focused Extension Host run passed 3/3
CI workflow matrix	Passed	68/68 contract tests; both new CI shards passed
Failed-scenario recheck	Passed	Every previously failed job passed
Full PR CI	Failed	New unrelated dynamic-debug teardown lock

Overall Result

ISSUES REMAIN

The coordinated-build product behavior and the new extension E2E coverage worked as intended.
The deterministic CLI test failure was corrected, and every previously failed scenario passed on
the updated head. The latest CI run is red only because a different dynamic-debug E2E test passed
its assertion and then hit a Windows EBUSY cleanup lock.

A separate valid review concern remains: the PR description claims atomic and symlink-safe
.gitignore behavior that is not present at final head. Testing confirms the current templates and
initialization paths do not add .aspire/.

Recommendations

1. Resolve the remaining .gitignore review concern or update the PR description and intended
   behavior explicitly.
2. Retry the Windows dynamic-debug-configuration shard; its functional test passed and only temp
   directory cleanup failed.
3. No additional coordinated-build product correction is indicated by these test results.

Artifact Locations

• Test root: C:\Users\karolz\AppData\Local\Temp\aspire-pr-test-19678-8f7546b4
• Report: C:\Users\karolz\AppData\Local\Temp\aspire-pr-test-19678-8f7546b4\pr-19678-testing-report.md
• Recheck logs: recheck-cli-test.log, recheck-extension-unit.log,
  recheck-install.log, and recheck-version.txt
• Downloaded CI diagnostics:
  C:\Users\karolz\AppData\Local\Temp\aspire-pr-test-19678-8f7546b4\ci-failures

[github-actions]

Tests selector

53 / 99 PR test projects · 5 PR jobs · 2 advisory-only targets, from 66 changed files.

Selected PR test projects (53 / 99)

Aspire.Cli.EndToEnd.Tests, Aspire.Cli.Tests, Aspire.Hosting.Analyzers.Tests, Aspire.Hosting.Azure.Kubernetes.Tests, Aspire.Hosting.Azure.Kusto.Tests, Aspire.Hosting.Azure.Tests, Aspire.Hosting.Blazor.Tests, Aspire.Hosting.Browsers.Tests, Aspire.Hosting.CodeGeneration.Go.Tests, Aspire.Hosting.CodeGeneration.Java.Tests, Aspire.Hosting.CodeGeneration.Python.Tests, Aspire.Hosting.CodeGeneration.Rust.Tests, Aspire.Hosting.CodeGeneration.TypeScript.Tests, Aspire.Hosting.Containers.Tests, Aspire.Hosting.DevTunnels.Tests, Aspire.Hosting.Docker.Tests, Aspire.Hosting.Dotnet.Tests, Aspire.Hosting.DotnetTool.Tests, Aspire.Hosting.EntityFrameworkCore.Tests, Aspire.Hosting.Foundry.Tests, Aspire.Hosting.Garnet.Tests, Aspire.Hosting.GitHub.Models.Tests, Aspire.Hosting.Go.Tests, Aspire.Hosting.Java.Tests, Aspire.Hosting.JavaScript.Tests, Aspire.Hosting.Kafka.Tests, Aspire.Hosting.Keycloak.Tests, Aspire.Hosting.Kubernetes.Tests, Aspire.Hosting.Maui.Tests, Aspire.Hosting.Milvus.Tests, Aspire.Hosting.MongoDB.Tests, Aspire.Hosting.MySql.Tests, Aspire.Hosting.Nats.Tests, Aspire.Hosting.OpenAI.Tests, Aspire.Hosting.Oracle.Tests, Aspire.Hosting.Orleans.Tests, Aspire.Hosting.PostgreSQL.Tests, Aspire.Hosting.Python.Tests, Aspire.Hosting.Qdrant.Tests, Aspire.Hosting.RabbitMQ.Tests, Aspire.Hosting.Radius.Tests, Aspire.Hosting.Redis.Tests, Aspire.Hosting.RemoteHost.Tests, Aspire.Hosting.Rust.Tests, Aspire.Hosting.Seq.Tests, Aspire.Hosting.SqlServer.Tests, Aspire.Hosting.Testing.Tests, Aspire.Hosting.Tests, Aspire.Hosting.Valkey.Tests, Aspire.Hosting.Yarp.Tests, Aspire.Managed.Tests, Aspire.Playground.Tests, Infrastructure.Tests

Selected PR jobs (5)

cli-starter-validation, extension-e2e, extension-unit, polyglot, typescript-api-compat

Advisory workflow impact (2)

• Aspire.EndToEnd.Tests (outerloop-only)
• deployment-e2e (schedule/dispatch-only)

---

How these were chosen — grouped by what changed

⚠️ 31 of the 54 selected test projects come from a single change — tests/Aspire.Hosting.TestUtilities/Helpers/CallbackLifecycleHook.cs.

🧪 tests/Aspire.Hosting.TestUtilities/Helpers/CallbackLifecycleHook.cs (changed test)
→ 31 via the project graph

show 31

Aspire.Hosting.Azure.Kubernetes.Tests, Aspire.Hosting.Azure.Kusto.Tests, Aspire.Hosting.Browsers.Tests, Aspire.Hosting.Containers.Tests, Aspire.Hosting.DevTunnels.Tests, Aspire.Hosting.Docker.Tests, Aspire.Hosting.DotnetTool.Tests, Aspire.Hosting.EntityFrameworkCore.Tests, Aspire.Hosting.Foundry.Tests, Aspire.Hosting.Garnet.Tests, Aspire.Hosting.GitHub.Models.Tests, Aspire.Hosting.Go.Tests, Aspire.Hosting.Kafka.Tests, Aspire.Hosting.Keycloak.Tests, Aspire.Hosting.Kubernetes.Tests, Aspire.Hosting.Milvus.Tests, Aspire.Hosting.MongoDB.Tests, Aspire.Hosting.MySql.Tests, Aspire.Hosting.Nats.Tests, Aspire.Hosting.OpenAI.Tests, Aspire.Hosting.Oracle.Tests, Aspire.Hosting.Orleans.Tests, Aspire.Hosting.PostgreSQL.Tests, Aspire.Hosting.Python.Tests, Aspire.Hosting.Qdrant.Tests, Aspire.Hosting.RabbitMQ.Tests, Aspire.Hosting.Redis.Tests, Aspire.Hosting.Seq.Tests, Aspire.Hosting.SqlServer.Tests, Aspire.Hosting.Valkey.Tests, Aspire.Hosting.Yarp.Tests

🔧 src/Aspire.Hosting/ApplicationModel/CommandsConfigurationExtensions.cs (changed source)
→ 11 via the project graph: Aspire.Hosting.Analyzers.Tests (2 hops), Aspire.Hosting.Azure.Tests, Aspire.Hosting.CodeGeneration.Go.Tests, Aspire.Hosting.CodeGeneration.Java.Tests, Aspire.Hosting.CodeGeneration.Python.Tests, Aspire.Hosting.CodeGeneration.Rust.Tests, Aspire.Hosting.CodeGeneration.TypeScript.Tests, Aspire.Hosting.Maui.Tests, Aspire.Hosting.RemoteHost.Tests, Aspire.Hosting.Testing.Tests (2 hops), Aspire.Playground.Tests

🔧 src/Shared/PathNormalizer.cs (changed source)
→ 3 via the project graph: Aspire.Hosting.Java.Tests, Aspire.Hosting.JavaScript.Tests, Aspire.Hosting.Rust.Tests

🧪 tests/Aspire.Hosting.Tests/Dcp/ExecutableLaunchPlanTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests
→ 2 via the project graph: Aspire.Hosting.Blazor.Tests, Aspire.Hosting.Radius.Tests

📦 affected project Aspire.Cli
→ 1 test: Aspire.Cli.EndToEnd.Tests

📦 affected project Aspire.Hosting
→ 1 test: Aspire.EndToEnd.Tests

📄 .github/workflows/extension-e2e-tests.yml (changed)
→ 1 directly: Infrastructure.Tests

📄 playground/DotnetProject/DotnetProject.AppHost/AppHost.cs (changed)
→ 1 directly: Aspire.Playground.Tests

📄 playground/DotnetProject/TypeScriptAppHost/apphost.mts (changed)
→ 1 directly: Aspire.Playground.Tests

🔧 src/Aspire.Hosting.Dotnet/Aspire.Hosting.Dotnet.csproj (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.Dotnet/AssemblyInfo.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.Dotnet/DotnetProjectBuildArtifactManager.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.Dotnet/DotnetProjectBuildCoordinator.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.Dotnet/DotnetProjectBuildEnvironmentCallbackAnnotation.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.Dotnet/DotnetProjectBuildResource.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.Dotnet/DotnetProjectHostingExtensions.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.Dotnet/DotnetProjectMetadata.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Hosting.Dotnet/DotnetProjectRunPropertiesResolver.cs (changed source)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🔧 src/Aspire.Managed/Aspire.Managed.csproj (changed source)
→ 1 via the project graph: Aspire.Managed.Tests

🧪 tests/Aspire.Cli.Tests/BundleServiceIntegrationTests.cs (changed test)
→ 1 directly: Aspire.Cli.Tests

🧪 tests/Aspire.Cli.Tests/Commands/InitCommandTests.cs (changed test)
→ 1 directly: Aspire.Cli.Tests

🧪 tests/Aspire.Cli.Tests/Commands/NewCommandTemplateConfigPersistenceTests.cs (changed test)
→ 1 directly: Aspire.Cli.Tests

🧪 tests/Aspire.Cli.Tests/HeldFileLeaseTests.cs (changed test)
→ 1 directly: Aspire.Cli.Tests

🧪 tests/Aspire.Cli.Tests/Scaffolding/ChannelReseedTests.cs (changed test)
→ 1 directly: Aspire.Cli.Tests

🧪 tests/Aspire.Cli.Tests/TestServices/FakeAppHostServerSession.cs (changed test)
→ 1 directly: Aspire.Cli.Tests

🧪 tests/Aspire.Cli.Tests/Utils/PathNormalizerTests.cs (changed test)
→ 1 directly: Aspire.Cli.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/Aspire.Hosting.Dotnet.Tests.csproj (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectBuildArtifactManagerTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectBuildCoordinatorTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectBuildEnvironmentTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectPublicApiTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectResourceTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/DotnetProjectRunPropertiesResolverTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.Dotnet.Tests/Snapshots/DotnetProjectBuildCoordinatorTests.GeneratedTraversalProjectContainsOnlyUniqueProjectsInModelOrder.verified.proj (changed test)
→ 1 directly: Aspire.Hosting.Dotnet.Tests

🧪 tests/Aspire.Hosting.Tests/DebugSupportExtensionsTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

🧪 tests/Aspire.Hosting.Tests/ExecutableResourceBuilderExtensionTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

🧪 tests/Aspire.Hosting.Tests/Pipelines/DistributedApplicationPipelineTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

🧪 tests/Aspire.Hosting.Tests/ProjectRebuilderResourceTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

🧪 tests/Aspire.Hosting.Tests/Publishing/PipelineExecutorTests.cs (changed test)
→ 1 directly: Aspire.Hosting.Tests

Job reasons

Job	Triggered by
cli-starter-validation	affected project Aspire.Cli
deployment-e2e	affected project Aspire.Cli
extension-e2e	• .github/workflows/extension-e2e-tests.yml, extension/loc/xlf/aspire-vscode.xlf, extension/package.nls.json, extension/src/capabilities.ts, extension/src/dcp/types.ts, extension/src/debugger/debuggerExtensions.ts, extension/src/debugger/languages/dotnet.ts, extension/src/loc/strings.ts, extension/src/test-e2e/coordinatedBuild.e2e.test.ts, extension/src/test/dotnetDebugger.test.ts, extension/src/testing/e2eStateFileBridge.ts, src/Aspire.Cli/Aspire.Cli.csproj, src/Aspire.Hosting.Dotnet/Aspire.Hosting.Dotnet.csproj, src/Aspire.Hosting.Dotnet/AssemblyInfo.cs, src/Aspire.Hosting.Dotnet/DotnetProjectBuildArtifactManager.cs, src/Aspire.Hosting.Dotnet/DotnetProjectBuildCoordinator.cs, src/Aspire.Hosting.Dotnet/DotnetProjectBuildEnvironmentCallbackAnnotation.cs, src/Aspire.Hosting.Dotnet/DotnetProjectBuildResource.cs, src/Aspire.Hosting.Dotnet/DotnetProjectHostingExtensions.cs, src/Aspire.Hosting.Dotnet/DotnetProjectMetadata.cs, src/Aspire.Hosting.Dotnet/DotnetProjectRunPropertiesResolver.cs, src/Aspire.Hosting/ApplicationModel/CommandsConfigurationExtensions.cs, src/Aspire.Hosting/ApplicationModel/DebugSupportExtensions.cs, src/Aspire.Hosting/ApplicationModel/ExecutableAnnotation.cs, src/Aspire.Hosting/ApplicationModel/ExecutableLaunchConfiguration.cs, src/Aspire.Hosting/ApplicationModel/ExecutableLaunchRecipe.cs, src/Aspire.Hosting/ApplicationModel/ProjectLaunchConfigurationFactory.cs, src/Aspire.Hosting/ApplicationModel/ProjectLaunchDefaultsAnnotation.cs, src/Aspire.Hosting/Aspire.Hosting.csproj, src/Aspire.Hosting/Dcp/ExecutableLaunchPolicy.cs, src/Aspire.Hosting/ExecutableResourceBuilderExtensions.cs, src/Aspire.Hosting/IProjectMetadata.cs, src/Aspire.Hosting/Pipelines/DistributedApplicationPipeline.cs, src/Aspire.Hosting/Pipelines/DistributedApplicationPipelineExtensions.cs, src/Aspire.Hosting/Pipelines/PipelineStep.cs, src/Aspire.Hosting/ProjectResourceBuilderExtensions.cs, src/Aspire.Hosting/ResourceBuilderExtensions.cs, tests/Aspire.Cli.Tests/BundleServiceIntegrationTests.cs, tests/Aspire.Cli.Tests/Commands/InitCommandTests.cs, tests/Aspire.Cli.Tests/Commands/NewCommandTemplateConfigPersistenceTests.cs, tests/Aspire.Cli.Tests/HeldFileLeaseTests.cs, tests/Aspire.Cli.Tests/Scaffolding/ChannelReseedTests.cs, tests/Aspire.Cli.Tests/TestServices/FakeAppHostServerSession.cs, tests/Aspire.Cli.Tests/Utils/PathNormalizerTests.cs • affected project Aspire.Cli
extension-unit	extension/loc/xlf/aspire-vscode.xlf, extension/package.nls.json, extension/src/capabilities.ts, extension/src/dcp/types.ts, extension/src/debugger/debuggerExtensions.ts, extension/src/debugger/languages/dotnet.ts, extension/src/loc/strings.ts, extension/src/test-e2e/coordinatedBuild.e2e.test.ts, extension/src/test/dotnetDebugger.test.ts, extension/src/testing/e2eStateFileBridge.ts
polyglot	affected project Aspire.Cli
typescript-api-compat	affected project Aspire.Cli

---

Selection computed for commit 9674105.

[Copilot]

🔵 Needs a closer look

The broad lifecycle, cross-process artifact, build, and IDE-launch changes warrant final human validation despite extensive coverage.

Review details

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

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

⚠️ CI Failure Analysis: Possible Flaky Test(s)

The CI build failed due to test failure(s) that appear unrelated to the PR changes. These may be flaky tests.

Suspected flaky test(s):

• Infrastructure.Tests.ExtensionChangelogFinalizedWorkflowTests.ReleaseBranchWithStaleExtensionBaseAdvanceFails in job Tests / No-package tests / Infrastructure (ubuntu-latest)
  • Error: Assert.Contains() Failure: Sub-string not found
    String: "::error file=extension/CHANGELOG.md,line=3,title=F"...
    Not found: "Finalized changelog range ends at"
  • Stack Trace (first frames):

    at Infrastructure.Tests.ExtensionChangelogFinalizedWorkflowTests.ReleaseBranchWithStaleExtensionBaseAdvanceFails() in /_/tests/Infrastructure.Tests/WorkflowScripts/ExtensionChangelogFinalizedWorkflowTests.cs:line 226
    

  • Why likely flaky: Test depends on ambient repo/branch state assumptions (changelog history) rather than PR content; previously seen failing on an unrelated PR (Emit otel from Cosmos Db Preview Emulator #15671) and tracked as a recurring flaky test.
• Aspire.Dashboard.Components.Tests.Pages.MetricsTests.ChangeResource_MeterAndInstrumentNotOnNewResources_InstrumentCleared in job Tests / No-package tests / Dashboard.Components (windows-latest)
  • Error: Microsoft.Data.Sqlite.SqliteException : SQLite Error 1: 'expected 0 columns for '' but got 18'.
  • Stack Trace (first frames):

    at Microsoft.Data.Sqlite.SqliteException.ThrowExceptionForRC(Int32 rc, sqlite3 db)
       at Microsoft.Data.Sqlite.SqliteCommand.PrepareAndEnumerateStatements()+MoveNext()
       at Aspire.Dashboard.Otlp.Storage.SqliteTelemetryRepository.MaterializeMetricDimensions(...) in SqliteTelemetryRepository.Metrics.Reads.cs:line 206
    

  • Why likely flaky: Known recurring intermittent SQLite in-memory column-count mismatch on Windows, observed across many unrelated PRs (5+ prior occurrences); PR does not modify Dashboard SQLite storage code.

Suggested actions:

• Re-run the failed CI jobs to confirm if the failure is intermittent
• If the test continues to fail, consider quarantining it using /quarantine-test <test name> <issue URL>
• Search existing issues to see if this test is already known to be flaky

You can re-run the failed jobs from the workflow run page.

[David Fowler (davidfowl)]

cc Chet Husk (@baronfel)