[spec] Add maui device list command spec to CLI design doc#34277
[spec] Add maui device list command spec to CLI design doc#34277
maui device list command spec to CLI design doc#34277Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 34277Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34277" |
maui device list command spec to CLI design docmaui device list command spec to CLI design doc
94cab3a to
805c3bc
Compare
Add 'maui device list' command specification to the CLI design doc, including: - Command syntax with --platform and --json options - Human-readable and JSON output schemas - Analysis of two discovery approaches (MSBuild vs native CLI) - Comparison table of pros/cons - Six real-world scenarios requiring project-free device enumeration - Recommended approach (direct native tool invocation) - Relationship to dotnet run --list-devices (complementary) - References to ComputeAvailableDevices targets in dotnet/android and dotnet/macios Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
805c3bc to
5c20b77
Compare
| - [simctl command-line tool](https://nshipster.com/simctl/) | ||
|
|
||
| [vibe-wpf]: https://github.com/jonathanpeppers/vibe-wpf | ||
| [appledev-tools]: https://github.com/Redth/AppleDev.Tools |
| | | Approach A (MSBuild) | Approach B (Native CLI) | | ||
| |---|---|---| | ||
| | **Project required** | Yes — needs `.csproj` | No | | ||
| | **Cross-platform** | One platform per call (per TFM) | All platforms in one call | |
There was a problem hiding this comment.
Why would you need to list all the platforms in one call? This will be really slow.
| 1. **AI agent bootstrapping** — An agent starting a "vibe coding" | ||
| session needs to discover available targets before scaffolding a | ||
| project. It cannot call `dotnet run --list-devices` because there | ||
| is no `.csproj` yet. |
There was a problem hiding this comment.
I don't understand, why does it need to know the devices before a project exists?
What is it going to do with the list of devices?
There was a problem hiding this comment.
- you can see this AI usage, AI wants to see if device exists before creating it for example, or know figure what it can launch.
- You can see this on CI, check if the device exists before creating one
There was a problem hiding this comment.
Can you share a screenshot/example?
There was a problem hiding this comment.
you can look at maui ci for example ,we list first the devices to understand if we need to create a emulator to then pass to appium script
There was a problem hiding this comment.
But you have the repo cloned and have a project?
There was a problem hiding this comment.
In the future, you should dotnet test a project and xharness will be deprecated?
There was a problem hiding this comment.
Far point on xharness, dotnet test is definitely the future there 👍
The main scenarios I keep coming back to are the ones where there truly is no project:
VS Code extension startup it does tis right now no .csproj to evaluate. I have this working today in vscode-maui, it calls maui device list --json on activation.
Environment diagnostics — "can my Mac see my iPhone?" is a diagnostic question, not a build question. Requiring a project for that feels like needing a .csproj to run adb devices 😄
AI agent cold start — agent in an empty directory asked to "build me an iOS app" needs to know if a simulator exists before it even scaffolds the project.
I think you do have a good point, but since this is shared with dotnet run via the android-tools whats the diff of having a wrapper here?
There was a problem hiding this comment.
@jonathanpeppers so you fine to merge this ? We can then in future maybe do a little better? if needed. We most have this merge already on android-tools so is just a case of the client tool use it.
Also we would need to update the client spec in the future as seems screenshot for example is now on MauiDevFlow on the maui labs repository
There was a problem hiding this comment.
I would focus on getting the first command -- and making the CLI actually exist before merging this.
There was a problem hiding this comment.
Merging now the cli exist on maui-labs
| | **Project required** | Yes — needs `.csproj` | No | | ||
| | **Cross-platform** | One platform per call (per TFM) | All platforms in one call | | ||
| | **Metadata** | Rich (RuntimeIdentifier, workload-specific fields) | Standard (id, description, type, status) | | ||
| | **Speed** | Slower (MSBuild evaluation + restore) | Fast (<2s, direct process calls) | |
There was a problem hiding this comment.
I doubt listing devices for all platforms will beat 2 seconds, do we have a measurement?
There was a problem hiding this comment.
I have a working version now on vscode it s what it looks like :) I can try give you a exact number
Note
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!
Summary
Adds the
maui device listcommand specification to the existing CLI design document (docs/design/cli.md). This command provides unified, cross-platform device enumeration without requiring a project context.See PR #33865 for the full DevTools spec.
What is added
Command:
maui device list [--platform <p>] [--json]Lists connected devices, running emulators, and available simulators across all platforms in a single call.
Two approaches analysis
The spec analyzes two discovery approaches and recommends the project-free one:
dotnet run --list-devices)maui device list)Scenarios requiring project-free discovery
.csprojyet)Recommended approach
maui device listuses direct native tool invocation (adb devices,simctl list,devicectl list). Device IDs are compatible withdotnet run --device, making them complementary:Other changes
ComputeAvailableDevicesMSBuild targets in dotnet/android and dotnet/macios