[hansmbakker]

This is a suggested approach for #54.

It defines custom Aspire resource commands that will make calls to the DevProxy API.

An OpenAPI spec was generated from https://github.com/dotnet/dev-proxy/blob/main/DevProxy/ApiControllers/ProxyController.cs and based on that the DevProxyApiClient was generated.

An interface was defined to have both resource types (executable and container-based) behave the same since they expose the same API.

Currently the WithDevProxyRecordingCommands is called always.

[hansmbakker]

I enabled Allow edits by maintainers - feel free to modify it if you think it needs to be different (e.g. different API client library than Refit), or if you think the Show logs and Generate JWT features also need to be disclosed.

[hansmbakker]

I see the API key authorization still needs to be added

[hansmbakker]

I added the API key authorization to the commands but I'm not sure whether I've done it the proper way especially for the container-based resource. Could you please have a look?

[hansmbakker]

Also it is still possible to add icons to the commands

[waldekmastykarz]

I added the API key authorization to the commands but I'm not sure whether I've done it the proper way especially for the container-based resource. Could you please have a look?

Will do! Thank you! I appreciate you working with us

[waldekmastykarz]

Thanks again for picking this up, @hansmbakker. Using custom resource commands is exactly the right way to do this, and your work made it easy to see what we need. I pushed a commit to your branch (dd80162) with a few changes. Here's what changed and why:

API token
Your question about the container token was a good one. Digging into it, reading token files from Dev Proxy's config folder turned out to be harder than it looks. On Windows Dev Proxy uses LocalApplicationData. The shared credentials folder can contain tokens from other or stale Dev Proxy instances. On Linux Docker or Podman, the bind-mounted folder can run into user-ID and permission issues, since Dev Proxy locks down that folder when it starts.

Instead, we'll add support in Dev Proxy for a DEV_PROXY_API_TOKEN environment variable. The AppHost now generates a token for each resource, passes it to Dev Proxy and uses it for the commands. That works the same for the executable and the container, with no file system access. If Dev Proxy doesn't support the variable yet, the command shows a clear message instead of a bare 401.

HTTP client
The commands make a single call (POST /proxy), so I swapped Refit for HttpClient + System.Net.Http.Json. That keeps the package free of extra dependencies for the AppHosts that use it.

Public API
I made the command extension internal, and the only DTO left is internal too. That way we don't commit to a public API we'd need to support while this feature evolves. We can expose more later if people need it.

Dashboard
The commands are now disabled unless the resource is running, and they have icons (Record / RecordStop) and descriptions.

OpenAPI spec
Since we no longer generate a client, I removed assets/openapi.yaml and its README mention.

Next steps
This depends on adding DEV_PROXY_API_TOKEN to Dev Proxy, so we'll merge it once a Dev Proxy release supports it. Let me know what you think, or if I missed something from your scenario. Thanks for working with us on this! 🙏

[hansmbakker]

@waldekmastykarz Thank you so much for your help and for thinking along!

I like the DEV_PROXY_API_TOKEN env var approach, that's much cleaner than reading it from a file that has platform-specific behaviour.

I understand your preference for avoiding a dependency, but I did like having a (generated) API client rather than manually coded HttpClient calls - to me the code looked a bit easier to read, and I think it would help with adding commands for the other interactive features (fetching the logs, generating a JWT, sending a mock request).

[waldekmastykarz]

I think we should make it easy for folks to generate clients that communicate with the Dev Proxy API, but I was hesitant including a dependency that would end up in everyone's applications. Since we own the API, we can take the "hit" and implement the client ourselves.

[Copilot]

🟡 Changes recommended

The linked Dev Proxy implementation ignores the supplied token environment variable, causing both recording commands to fail authentication.

1 open issue

• Recording commands use token mismatched with Dev Proxy server · New

What changed in this PR

This PR adds Aspire dashboard controls for Dev Proxy recording, addressing the recording workflow raised in issue #54.

Changes:

• Registers start and stop recording commands for executable and container resources.
• Sends authenticated API requests with endpoint checks and error handling.
• Documents the commands and their token-support requirement.

File	Description
README.md	Documents recording commands and required token support.
DevProxy.Hosting/​DevProxyResourceBuilderExtensions.cs	Enables recording commands for both resource types.
DevProxy.Hosting/​DevProxyCommandExtensions.cs	Implements command registration, token setup, and recording API requests.

_{Review effort: Balanced}