Add a design proposal for dotnet tool exec and dnx#334
Conversation
|
The name |
My opinion is that after 10 years it's OK to reuse the name |
|
I have currently implemented support for running my CLI as a MCP server via a command line option. Will I be able to detect if the tool has been invoked by the "exec" command, or do I need to publish another tool? |
@ErikEJ Why would you need to detect if the tool was run via I think that tools should behave the same whether they are run with |
|
@dsplaisted My CLI can run both as a "normal" CLI tool and a MCP server - see the link above. |
I think the normal CLI should also be runnable via |
|
@dsplaisted Cool, got it, thanks |
…s, these action items were covered. For dotnet tool exec: Clarify that tools executed via dotnet tool exec will be installed to the NuGet cache without adding them to a manifest. Remove the line about only tools that support direct execution being supported. Break out the discussion about calling by command into a separate section, noting that further discussion and feedback are needed. For dnx: Clarify that the DNX command will forward all parameters directly to .NET, avoiding logic in shell scripts. Update documentation to reflect that on Unix, the DNX script does not need a file extension and should be marked as executable. Add a consideration about potentially AOTing the DNX command in the future.
…cussion. Specifically, call out the versionless nature of the dnx script and why we're doing a dotnet dnx CLI command. Clarify that we should execute a local version of the tool if available.
Add including of @ command support Added comment about npx inspiration
Co-authored-by: Jan Jones <jan.jones.cz@gmail.com>
8 participants
This is an attempt to summarize our discussions from the WIP for dotnet tool exec and offline discussions about having a shortcut dnx:
dotnet/sdk#31103
dotnet/sdk#48443
For dnx, we need to decide if there are some flags automatically set like --ignore-failed-sources or --yes.