The dotnet CLI

Create, build and run .NET projects from the command line, and read a .csproj file.

One tool for everything

When you install the .NET SDK you get a single command: dotnet. It creates projects, downloads packages, compiles, runs tests and publishes apps. Visual Studio, VS Code and Rider all call this same tool behind the scenes — so everything you learn here works with any editor.

Check your installation:

dotnet --version        # the SDK version, e.g. 8.0.425
dotnet --list-sdks      # every SDK installed on this machine

Create, run, repeat

dotnet new console -o HelloApp   # create a console project in a new HelloApp folder
cd HelloApp
dotnet run                       # build and run it

Hello, World!

That's a complete .NET development loop. Edit Program.cs, run dotnet run again, and your changes are compiled and executed.

Common templates

Command	Creates
`dotnet new console`	A command-line app
`dotnet new classlib`	A class library (reusable code, no entry point)
`dotnet new webapi`	An ASP.NET Core web API
`dotnet new xunit`	A test project
`dotnet new sln`	An empty solution file
`dotnet new list`	Show every installed template

The commands you'll use daily

Command	What it does
`dotnet build`	Compiles the project into `bin/Debug/net8.0/`
`dotnet run`	Builds if needed, then runs
`dotnet watch`	Runs, and rebuilds automatically every time you save
`dotnet test`	Builds and runs the tests
`dotnet add package <name>`	Adds a NuGet package (next lesson)
`dotnet publish -c Release`	Produces an optimized app ready to deploy
`dotnet clean`	Deletes build output

dotnet watch

While learning, dotnet watch is the nicest loop: leave it running, edit code, and see the result as soon as you save.

Inside the project file

dotnet new console creates two files. Program.cs holds your code. HelloApp.csproj describes the project:

<Project Sdk="Microsoft.NET.Sdk">
 
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
 
</Project>

Sdk — which build rules to use (Microsoft.NET.Sdk.Web for web apps).
OutputType — Exe builds a runnable program; libraries leave it out.
TargetFramework — the .NET version to build for (net8.0).
ImplicitUsings — automatically imports common namespaces like System and System.Linq.
Nullable — turns on null-safety warnings (Track 3).

Notice what's not there: a list of .cs files. Every .cs file in the folder is compiled automatically.

Debug vs Release

dotnet build uses the Debug configuration by default: easy to step through in a debugger, less optimized. dotnet build -c Release (and publish) uses Release: fully optimized, the one you deploy.

Solutions: grouping projects

Real applications are split into several projects — say, a web API, a class library with business logic, and a test project. A solution (.sln) groups them:

dotnet new sln -n Shop
dotnet new webapi  -o Shop.Api
dotnet new classlib -o Shop.Core
dotnet new xunit   -o Shop.Tests
 
dotnet sln add Shop.Api Shop.Core Shop.Tests
dotnet add Shop.Api reference Shop.Core      # the API uses the library
dotnet add Shop.Tests reference Shop.Core    # the tests test the library
 
dotnet build    # builds every project in the solution

Don't commit bin/ and obj/

Both folders are generated by every build. Add them to .gitignore — dotnet new gitignore creates a good one for you.

Key takeaways

dotnet new creates, dotnet run builds and runs, dotnet watch reruns on save.
A .csproj declares the SDK, target framework and packages — source files are included automatically.
Debug for development, Release for deployment.
A solution groups related projects; projects reference each other with dotnet add reference.

You will learn