New dotnet watch support for aspire

[tmat]

Adds more functionality to Aspire.Watch CLI tool. Aspire can invoke it via CLI or you can also run some of it in-proc, as needed.

Defines 3 CLI commands: host, server and resource.

host runs AppHost:

Watch.Aspire host
 --sdk E:\aspire\.dotnet\sdk\10.0.102

server runs Hot Reload server and you pass it a set of C# resource projects or .cs files for file-based apps. It also takes a unique named pipe name to listen on:

Watch.Aspire server
 --server NamedPipe_6CE8A258-A439-4459-A348-1546EA0E202C
 --resource AspireApp\AspireApp.ApiService\AspireApp.ApiService.csproj 
 --resource AspireApp\AspireApp.Web.cs

resource launches resource project:

Watch.Aspire resource 
  --server NamedPipe_6CE8A258-A439-4459-A348-1546EA0E202C 
  --entrypoint AspireApp\AspireApp.ApiService\AspireApp.ApiService.csproj

Watch.Aspire resource 
  --server NamedPipe_6CE8A258-A439-4459-A348-1546EA0E202C 
  --entrypoint AspireApp\AspireApp.Web.cs

This command also takes parameters like --environment, --launch-profile, etc.
It sends request to launch an app to the server.

---

Bidirectional control protocol (AppHost ↔ Watch Server)

This update adds a status/control pipe protocol between the AppHost and the Watch.Aspire server:

Status events (Watch Server → AppHost):
The watch server reports lifecycle events back to the AppHost over a named pipe (--status-pipe). The AppHost uses these to update resource states in the Dashboard:

• building / build_complete (with success/failure)
• hot_reload_applied
• restarting
• process_started / process_exited (with exit code)

Control commands (AppHost → Watch Server):
The AppHost sends commands to the watch server over a named pipe (--control-pipe):

• rebuild — triggers a forced rebuild and restart for specific projects

Dashboard integration:

• Each watched project resource gets a Rebuild button in the Dashboard that sends a rebuild command to the watch server
• Resource states update in real-time (Building → Starting → Running, or Build failed)

Crash recovery:

• When a watched process crashes (non-zero exit), the watch server signals the iteration to restart and waits for a file change before rebuilding
• The DCP resource command pipe stays alive across crash-restart cycles so the Dashboard connection is preserved

Other changes:

• DotnetSdkUtils expanded with TryGetSdkDirectoryAsync using dotnet --list-sdks for accurate SDK resolution (respects global.json)
• Watch server resource creation moved to WatchAspireEventHandlers (eventing subscriber) for cleaner separation from DcpExecutor
• Fixed .in.targets to use $(OS) != 'Windows_NT' instead of IsOsPlatform('OSX') for non-Windows DLL path resolution

[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/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 14327

Or

• Run remotely in PowerShell:

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

[tmat]

@davidfowl @karolz-ms

[davidfowl]

How is the host command special?

[tmat]

How is the host command special?

That one is equivalent to regular dotnet watch.

[tmat]

This allows restarting all resource projects, but wouldn't we rather want to restart individual resource projects?

[tmat]

This doesn't look right. Do we actually want to restart everything if one of the resource process crashes? I guess not. We want to restart just that one process, right?

[tmat]

Superseded by #14947