CLI Tools & Shell Workflows for .NET Devs

For a .NET shop, the CLI is no longer a developer-only surface. It is where the build agent runs, where the compliance script reaches into the project graph, where the audit pipeline emits its evidence, and where the next operator after you will discover what your team actually shipped. The articles in this collection treat the .NET CLI as a DevOps interface first and a scaffolding tool second.

A recurring theme is machine-readable output. A command that prints a friendly table is fine for a human; the same command emitting structured JSON is what makes it useful inside a pipeline. The .NET 10 CLI moved meaningfully in this direction, and the articles cover where the schemas are stable, where they are still being shaped, and how to wrap older commands whose output was never designed to be parsed.

Tab completion gets specific attention because it is the single feature that decides whether a CLI gets used to its potential or used as a copy-paste target. The shell completion model in .NET, how it differs between PowerShell and bash, and how a tool author exposes completion for custom commands all belong here. A good CLI teaches its own grammar; a bad one demands that the user keep a cheat sheet.

Ephemeral tools — dotnet tool exec, one-shot global tools, and the workflows that run a tool once inside a build container and never install it — are treated as a category of their own. They change how a team thinks about dependencies. A tool that lives only for the duration of a pipeline step is much cheaper to adopt and much safer to update than one wired into a developer machine for a year.

Audit trails matter too. CLI tools that touch production data, rotate secrets, or modify infrastructure should leave traceable evidence behind. Articles cover how to build that into a custom CLI from day one rather than retrofitting it after a compliance review, and which audit patterns translate cleanly into SIEM ingestion.