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.

Your Privacy Docs Are Fiction: Let's Fix That with .NET CLI Tools

Spreadsheet-based privacy audits examine yesterday’s system while today’s code deploys undocumented PII. Build .NET CLI tools that discover all personal data, catch expired consents, and verify deletions. Then fail builds when compliance breaks.

Security Tests That Prove Themselves

Your security tests run. They pass. But can you prove when they ran and against which code version? Most security testing lives in Word documents, Postman exports, and screenshot folders on SharePoint. The tests themselves might be valid. The evidence trail is not. This article shows how to build CLI-based test suites using xUnit and WebApplicationFactory that generate their own proof: structured logs with timestamps, commit hashes, and correlation IDs captured automatically in CI/CD pipelines. No more quarterly reports that could have been written yesterday. Instead, 847 test executions across 23 deployments, each linked to a specific commit and preserved for 90 days.

Certified, Filed, Forgotten: The Compliance Trainwreck

Organization gets certified. Consultants cash their checks. Documentation gets filed somewhere. Then compliance becomes a Word document ritual: screenshot the portal, sign the checklist, ship it. Three months later, an audit exposes configuration drift, hardcoded secrets, and vulnerable dependencies nobody noticed. The forensic evidence disagrees with the signatures. The fix isn’t stricter sign-offs or more checklists. It’s treating compliance as an engineering problem with automated CLI tools that run on every deployment.

Who Ran That Migration?

Three hours into a production incident, someone asks the obvious question. Silence. The terminal closed, the build log expired last week, and your migration tool printed “Success” before forgetting everything. This scenario repeats constantly: privileged CLI operations that modify production systems, then vanish without a trace. The fix requires discipline, not genius: structured logging, user identity tracking, and persistent storage.

.NET CLI 10 – Microsoft Finally Realizes DevOps Exists

The .NET CLI? Reliable. Boring. You run dotnet build, dotnet test, dotnet publish, done. Real DevOps work happens in Dockerfiles, CI/CD configs, and specialized tools. The CLI does its job but was never built for actual operational workflows.

.NET 10 changes this. Four additions that sound minor but fix real problems I’ve hit in production pipelines for years: native container publishing, ephemeral tool execution, better cross-platform packaging, and machine-readable schemas. Not flashy. Not keynote material. But they’re the kind of improvements that save hours every week once you’re running them at scale.

Will they replace your current workflow? Depends on what you’re building. Let’s look at what actually changed.