8000 Support ephemeral execution for `dotnet tool run` similar to npx, docker, and uv · Issue #47517 · dotnet/sdk · GitHub
[go: up one dir, main page]
Skip to content

Support ephemeral execution for dotnet tool run 8000 similar to npx, docker, and uv #47517

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
JonDouglas opened this issue Mar 12, 2025 · 6 comments
Open

Support ephemeral execution for dotnet tool run similar to npx, docker, and uv #47517

JonDouglas opened this issue Mar 12, 2025 · 6 comments
Assignees
@baronfel
Labels
Area-Tools untriaged Request triage from a team member

Comments

@JonDouglas
Copy link
JonDouglas commented Mar 12, 2025 •
edited
Loading

Is your feature request related to a problem? Please describe.

In the AI-world, MCPs are becoming popular as a paradigm to share prompts, tools, and resources with a client. These are often run through package managers or docker environments in temporary fashion.

Describe the solution you'd like

Many ecosystems are using tools like npx, docker, uv, in various ways, but mostly in isolated, temporary environments where it downloads the dependency into an ephemeral environment, runs the thing, and then the environment is torn down

dotnet tool run could simply just support this by default if it isn't specified in the scope of a local environment where it would look for a local tool instead. Or a parameter to specify this is --ephermeral/temporary is fine too.

Additional context

https://github.com/modelcontextprotocol/servers

Related: #31103
@ghost ghost added Area-Tools untriaged Request triage from a team member labels Mar 12, 2025
@Redth
Copy link
Member
Redth commented Mar 12, 2025

It's also worth contemplating a similar short-hand for this like node has with npx being a package runner.

dotnet tool run --temp could be simplified to dnx or dntx.

@richlander
Copy link
Member

I think there are definitely some missing scenarios here. It would be good to see some documented, from other ecosystems and/or fake .NET ones.

Docker doesn't strike me as another ecosystem in the way npx is. I think the way to use both Node and .NET in Docker is well understood at this point and folks are successful using it in both weird and wonderful ways.

"temporary" is a good goal. "secure" is not. We're not in the business of providing secure environments, but relying on other systems to do that. We should avoid creating an experience that is as convenient and attractive as curl | sh.

@JonDouglas
Copy link
Author

I think there are definitely some missing scenarios here. It would be good to see some documented, from other ecosystems and/or fake .NET ones.

Docker doesn't strike me as another ecosystem in the way npx is. I think the way to use both Node and .NET in Docker is well understood at this point and folks are successful using it in both weird and wonderful ways.

"temporary" is a good goal. "secure" is not. We're not in the business of providing secure environments, but relying on other systems to do that. We should avoid creating an experience that is as convenient and attractive as curl | sh.

https://docs.npmjs.com/cli/v9/commands/npx?v=true

https://docs.astral.sh/uv/#tools

Let me clarify the scenario more explicitly.

We need a lightweight, temporary tool execution mechanism in the .NET ecosystem, similar to what Node's npx does. Specifically allowing quick, isolated, one-off execution of .NET-based tools without permanently affecting your global or local toolset.

The comparison to Docker wasn't about mimicking DOcker or containerization itself, rather illustrating that some developers use container tools to temporarily execute commands without polluting their permanent environment. Docker itself is not the intended analogy here but highlights the concept of transient tool exceution.

We’re also not inherently guaranteeing a secure sandbox or replicating something like curl | sh. Security concerns would continue to be addressed through existing, trusted mechanisms. This solution would rely heavily on our established NuGet infrastructure.

This approach provides clear usability benefits and has already been implemented in multiple ecosystems. Allowing .NET devs to execute tools quickly, frictionlessly, and temporarily would significantly improve many scenarios, especially for MCP.

@gaoconggit
Copy link

https://github.com/Redth/npx-dntx

I also think dotnet's mcp needs this

This was referenced Mar 31, 2025
Closed
Merged
@stvansolano
Copy link

Would be possible to extend @Redth npx-dntx to run/support packages hosted in nuget directly? That will aim MCP developed via the SDK and boost NuGet usage itself

e.g: npx dntx @nuget/modelcontextprotocol/csharp-sdk/samples/QuickstartWeatherServer (technically, whatever MCP ready to use which just requires passing an argument, like OPEN_API_KEY)

cc @stephentoub

@baronfel
Copy link
Member

See also #31103 for related discussion/spec/planning.

@joelverhagen joelverhagen mentioned this issue May 20, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@baronfel baronfel

Labels
Area-Tools untriaged Request triage from a team member
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@Redth @baronfel @JonDouglas @richlander @stvansolano @gaoconggit
0