Update Project Resource v2 plan for file app builds

[Damian Edwards (DamianEdwards)]

Description

The Project Resource v2 plan excluded file-based apps from its coordinated initial build, leaving file apps that share #:project dependencies vulnerable to concurrent writes in shared bin and obj directories.

This updates the plan to:

• Build project entrypoints together through the generated .slnx.
• Build file-based entrypoints serially behind the same startup barrier.
• Suppress launch-time rebuilds in watch, non-watch, and IDE/debug paths.
• Optionally evaluate file-app ProjectReference items with dotnet build <app.cs> --no-restore -getItem:ProjectReference -getResultOutputFile:<path>, adding resolved .csproj FullPath values to the initial .slnx.
• Extend the planned tests and playground coverage to include multiple file apps and project resources sharing dependencies.

Serialized file-app builds remain the correctness fallback when evaluated-item discovery is not implemented.

Fixes #19037

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

[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 -- 19086

Or

• Run remotely in PowerShell:

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

[Copilot]

Pull request overview

Updates the Project Resource v2 plan to coordinate file-based app builds and prevent shared-output races.

Changes:

• Serializes file-app builds behind the .slnx build.
• Suppresses launch-time rebuilds.
• Expands planned regression coverage.

Suppressed comments (2)

docs/plans/project-v2-csharpprogram-watch.md:375

• Session 5 should not instruct the implementation to consume dotnet reference list --file as .slnx input: its output is human-oriented, includes non-project file references, and preserves unresolved directive text. Remove this optimization from the session or first require a resolved, project-only SDK output contract.

(§5.3): build a temp `.slnx` containing all project entrypoints and, on supported SDKs, the references returned
by `dotnet reference list --file <app.cs>`; then serially `dotnet build` every file-based entrypoint so the SDK
discovers and builds its complete `#:project` graph without overlapping another build. Treat both phases as one
startup barrier **identically for watch and non-watch**; stream logs; fail fast; launch from the result with
build suppression. The reference-list optimization must be SDK-gated and must not replace the serial fallback.

docs/plans/project-v2-csharpprogram-watch.md:214

• This discovery step cannot reliably produce the set described here. The SDK's GetReferencesForDisplay() emits each directive's original text and mixes project references with file-app references; it does not resolve project directories, relative paths, or MSBuild expressions to .csproj files. Feeding that human-readable output into SolutionPersistence can therefore add invalid entries. Use a resolved project-only contract, or omit this optional phase and retain the serialized fallback.

1. Collect and de-duplicate all project-based `DotnetProjectResource` `.csproj` entrypoints. As an optional
   optimization, when the active SDK is `10.0.400` or `11.0.100-preview.7` and later, run
   `dotnet reference list --file <app.cs>` for each file-based entrypoint and add its discovered `#:project`
   references to the same set. Generate a temp `.slnx` (`Microsoft.VisualStudio.SolutionPersistence`) from
   that set and run one coordinated `dotnet build`. Older SDKs skip discovery and rely on the serialized

[Damian Edwards (DamianEdwards)]

ah interesting! What about using dotnet build app.cs -getItems:ProjectReference instead?

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

docs/plans/project-v2-csharpprogram-watch.md:228

• IProjectMetadata.SuppressBuild cannot currently suppress the "project" IDE launch build. It only adds --no-build to process arguments; ProjectLaunchConfigurationFactory does not read it, and ProjectLaunchConfiguration has no no-build field because the IDE owns the build. F5 can therefore rebuild a shared dependency after the barrier, contradicting this PR's launch-time build-suppression guarantee. The plan needs an explicit IDE/DCP contract change (or a different launch path) that actually disables that build.

   installed, mark each resource's `IProjectMetadata.SuppressBuild` as `true` so both plain process launches
   and the `"project"` IDE/debug path consume the coordinated outputs. Update both argument-generation paths

[Adam Ratzman (adamint)]

Does anything actually start this server? §5.2 adds it with WithExplicitStart, while WaitForStart(server) only waits; it does not start an explicit-start dependency. That leaves the server NotStarted and every service waiting forever. I think the plan should either remove WithExplicitStart and auto-start it after the build barrier, or define the code path that explicitly starts it.

[Adam Ratzman (adamint)]

What rebuilds a file app after the initial barrier? AddLifeCycleCommands intentionally gives file apps no Rebuild command or rebuilder because each start currently rebuilds them. Once every later start uses --no-build, an edit followed by Restart just runs stale output (and a cleaned cache will not start at all). Could the plan route Start/Restart through the serialized coordinator, or retain a build path after the initial launch?

[Adam Ratzman (adamint)]

Could we add failure and cancellation coverage to this verification? The barrier is the startup gate, but these scenarios only cover successful builds. A failing or cancelled file-app build should prove later builds do not run, the watch server and services never start, and the active process is terminated and cleaned up.

[Adam Ratzman (adamint)]

I found two lifecycle blockers that I think need to be resolved before this plan is ready: the explicit-start watch server has no start path, and always suppressing file-app builds removes rebuild semantics for Start/Restart. I also left a test coverage comment for barrier failure and cancellation. Details inline.

[Adam Ratzman (adamint)]

Which configuration does this build use? Launches pass the AppHost configuration, so a Release app host would get a Debug .slnx build plus a --no-build --configuration Release launch and no outputs to run. Line 221 already says the file-app phase must use the launch inputs; could we extend that to the .slnx build and the -getItem query, and name the single configuration source?

[Adam Ratzman (adamint)]

This says shared references never have concurrent writers, but the barrier only collects DotnetProjectResource. Path-based AddProject(name, path) and AddCSharpApp stay unchanged under D2 and still build at launch, so a v1 file app sharing a #:project library with a v2 one can still race. Could we scope this guarantee to the DotnetProjectResource set and call mixed v1/v2 graphs a known limitation?