5 Essential .NET CLI Commands Every Developer Should Know

Checking Your Environment with dotnet --info

[0:31 - 1:25] Before running any project commands, Tim starts by verifying the development environment. The dotnet command on its own confirms that the CLI is installed and accessible on your path, but dotnet --info goes further:

dotnet --info

dotnet --info

This prints out every SDK and runtime version installed on your machine, along with the operating system details and the active architecture. Tim demonstrates this on .NET 10, but the command works identically on any version. Knowing what you have installed is especially helpful when debugging version mismatches or verifying that a CI server mirrors your local setup.

Command 1: dotnet build

[2:16 - 3:44] The first command compiles your project without launching it:

dotnet build

dotnet build

Running this from the project directory reads the .csproj file, resolves dependencies, and produces compiled output under the bin folder. Tim points out that compilation is its own distinct step, separate from execution. That separation matters when you want to verify that your code compiles cleanly before pushing to a repository or handing off to a build server.

The .NET SDK handles dependency resolution during the build process, pulling any missing NuGet packages and ensuring all referenced assemblies are present. If something fails at this stage, the error messages point directly to the problem, whether it is a missing reference, a syntax error, or a target framework mismatch. Catching those issues before running the application saves time in the overall development cycle.

Command 2: dotnet run

[3:44 - 5:42] Where build stops at compilation, run takes the next step and launches the application:

dotnet run

dotnet run

This compiles the project (if needed) and then executes the resulting output. For a console application, that means running it in the terminal. For a web project, the built-in Kestrel server starts and the app becomes available at a local URL.

Tim demonstrates this with a web application, navigating to the running site in a browser to confirm everything loads correctly. The key distinction between build and run is that run produces a live, interactive result. During active development, this is the command you will use most frequently to test changes and see their effect.

Command 3: dotnet watch

[5:42 - 7:06] Stopping the application, making a change, and restarting it gets tedious quickly. The watch command eliminates that cycle:

dotnet watch

dotnet watch

This wraps the run process in a file watcher. When you save a change to any source file, the CLI detects the modification and automatically recompiles and refreshes the application. For web applications built with ASP.NET Core, changes to Razor files, CSS, and C# code appear in the browser without a manual restart.

Tim shows the hot reload behavior in action: editing a page, saving, and seeing the update reflected immediately. This tight feedback loop is valuable during UI work, where small adjustments happen constantly. Instead of cycling through stop-edit-rebuild-launch, you stay focused on the code and let the tooling handle the rest.

Command 4: dotnet clean

[7:06 - 7:56] Build artifacts accumulate in the bin and obj directories over time. Occasionally, stale compiled files cause confusing behavior where your latest code changes do not seem to take effect, or where a build succeeds locally but fails on a fresh machine. The clean command addresses this:

dotnet clean

dotnet clean

Running it removes the contents of the output directories so your subsequent build starts from scratch. Tim frames this as a troubleshooting tool rather than something you run after every change. When your project behaves unexpectedly and you suspect cached output is the culprit, clean followed by build ensures you are working with a truly fresh compilation.

This habit is particularly useful when switching branches in version control, upgrading a dependency to a new major version, or resolving intermittent build warnings that seem to appear and disappear without a clear cause.

Command 5: dotnet publish

[7:56 - 9:01] The final command bridges the gap between development and deployment:

dotnet publish

dotnet publish

While build produces output suitable for local debugging, publish creates a deployment-ready package. The compiled assemblies, configuration files, static assets, and any required runtime components land in a publish folder that you can copy directly to a server.

The distinction between build and publish catches some developers off guard. The build output includes debugging symbols and references that are useful during development but unnecessary (and sometimes undesirable) in production. Publishing strips those extras and organizes the output for its target environment. When deploying to Docker or uploading to a cloud host, the published output is what belongs in your final image or release package.

Wrapping Up: Five Commands, One Workflow

[9:01 - 9:15] Tim closes by listing all five together: dotnet build, dotnet run, dotnet watch, dotnet clean, and dotnet publish. Taken as a set, they cover the core development loop from compilation through deployment. Each one serves a specific purpose, and knowing when to reach for each gives you a level of control that clicking IDE buttons alone does not provide.

Conclusion

[9:15 - 9:30] These five CLI commands handle the tasks you perform most often during development: compiling, running, live-reloading, clearing stale output, and packaging for release. They work across every .NET project type and every operating system the SDK supports.

The next time you open a terminal, whether on your local machine, inside a container, or on a remote server, you already have the vocabulary to move through the full development cycle without a graphical interface.

Example Tip: You can chain clean and build into a single line with dotnet clean && dotnet build. This guarantees a from-scratch compilation in one step, which is especially handy when troubleshooting issues that persist across incremental builds.

Watch full video on his YouTube Channel and gain more insights on .NET CLI essentials.