You are familiar with the steps involved if you have ever desired to utilize a.NET command-line tool just once. After installing and using the tool, you either remove it or leave it permanently in your global tool list after realizing you just required it for that one activity. When you multiply it over a team or a build pipeline, you get clutter, version drift, and a surprising amount of friction for something that ought to be easy. One-shot tool execution, a feature in Microsoft 10, solves this. It eliminates the need for formal installation by enabling you to download and execute a.NET program with only one command. The concept will seem familiar to anyone who has used npx in the JavaScript realm.
The traditional method
The old way
To appreciate what changed, it helps to remember the two ways you used to get a tool onto a machine.
A global install put the tool on your PATH for the whole user account:
That works, but global state is exactly the kind of thing that quietly accumulates. Six months later your machine has a dozen tools you installed for one-off tasks and can’t remember the purpose of. This becomes worse when two projects might need different versions of the same global tool and step on each other.
A local install scoped the tool to a project via a manifest, which was even more tightly coupled with the system:
Both approaches share the same fundamental process of installing a separate process, apart from running step. If all you want is to run the thing once, you’re forced to install. This is where One-shot execution comes into the picture.
The dotnet tool exec command
The feature is a new command, dotnet tool exec. It executes a .NET tool without installing it globally or locally. Here’s what running a tool looks like:
The first time you reach for a tool that isn’t already present, the CLI prompts you to confirm the download before it proceeds.
The — source option points at where the package should come from. You can aim it at a local folder, as in the above example, or at a private or public NuGet feed. By default, CLI uses your configured package sources, just like a normal restore.
Choosing which version runs
By default, the command installs the latest available version of the tool. When you need any specific version then you can define with ‘@version’.
It respects your local manifests
One detail elevates this from “neat trick” to “actually trustworthy in a real project”: one-shot execution honors local tool manifests. If you run a tool from a directory that has a .config/dotnet-tools.json file nearby, the CLI uses the version pinned in that manifest instead of grabbing the latest available.
This is exactly the behavior you want. Teams that already pin their tool versions for reproducibility don’t have to think about whether one-shot execution will quietly pull something newer. The version everyone agreed on is the version that runs, whether a teammate installed it the traditional way or fired it off on demand.
The dnx shortcut
dotnet tool exec is descriptive, but it’s also a tedious task when you’re typing it dozens of times a day. .NET 10 introduces a streamlined script called dnx that makes the common case as short as possible:
Under the hood, dnx simply forwards its arguments to the dotnet CLI for processing. Because the real logic lives inside the CLI rather than in the script itself, the behavior can evolve over time without anyone needing to swap out the dnx script on their machine.
Handling the prompt in automation
The interactive confirmation is great at a keyboard and a problem in a pipeline, where there’s no human to answer “y” every time. The general pattern in the .NET 10 CLI is that interactivity is enabled by default in interactive terminals and can be turned off for non-interactive scenarios by passing — interactive false. In a CI job you’ll want to make sure the download proceeds without waiting on input, so combine one-shot execution with non-interactive settings and an explicit version pin.
A few practical use cases
The feature shines anywhere a tool is needed briefly. A few scenarios are:
- Evaluating a tool before committing to it.
- Bootstrapping a fresh environment.
- Ephemeral CI/CD agents.
- Occasional maintenance tasks.
Getting started
If you’re on .NET 10 or later, you already have everything you need. Pick a tool and run it:
Confirm the download when prompted, and that’s it. No install, no cleanup, no leftover.
Conclusion
One-shot tool execution is a small command with an outsized effect on how comfortable .NET tooling feels day to day.
- Run without installing. dotnet tool exec fetches and runs a .NET tool in a single step, with no global or local install to manage afterward, and dnx is the short alias for the everyday case.
- You can control versions. The latest version runs by default. You can pin any version with package@version.
- It’s built for automation. Pair it with —interactive false and an explicit version pin in CI so downloads proceed without hanging on a confirmation prompt, which makes it a natural fit for ephemeral build agents.
