Understanding the Build Process
By the end of this lesson
Explain what restore, build, run and publish each do, and pick the right one.
dotnet run does several things at once, which is convenient and occasionally confusing. Knowing the separate steps helps when one of them is what fails.
Restore
Reads the project file and downloads the packages it references. Runs automatically when needed. Failures here are usually network or feed problems, not code problems.
Build
Compiles your source into intermediate code and writes it to bin. This is where compile errors appear.
Run
Starts the compiled program. Errors here are run-time errors — your code compiled fine but did something invalid.
Publish
Produces a self-contained output folder ready to deploy, including only what is needed at run time.
# Compile only — quickest way to check for errors
dotnet build
# Compile and start
dotnet run
# Compile and run tests
dotnet test
# Produce deployable output in release configuration
dotnet publish -c Release
# Remove build outputs
dotnet cleanDebug and Release are different builds, and the difference matters:
| Debug (default) | Release | |
|---|---|---|
| Optimisations | Off, to keep stepping predictable | On |
| Debug symbols | Full | Reduced |
| Speed | Slower | Faster |
| Use for | Development and debugging | Deployment and performance measurement |
One more distinction worth knowing early. dotnet publish can produce either a framework-dependent build, which needs the .NET runtime installed on the target machine, or a self-contained build, which bundles the runtime and runs anywhere. Containers typically use framework-dependent output on a runtime base image, since the runtime is already in the image.
Summary
- restore fetches packages, build compiles, run executes, publish produces deployable output
- Compile errors come from build; run-time errors come from run
- Debug is for developing; Release is for deploying and for any performance measurement
- Deploy publish output, not the bin folder
Practice
Attempt each one before opening the solution. Getting it wrong first is how the idea sticks.
Try it yourself
Try it yourself
Run dotnet build on your project and look inside bin. Then run dotnet publish -c Release -o ./publish and compare the contents of the two folders.
Show solution
The publish folder contains what is needed to run and nothing else. The bin folder carries additional build artifacts and debug files.
This is exactly why deployment uses publish output: it is the intended, minimal result rather than a working directory.
Knowledge check
Nothing is recorded and there is no score. The explanation appears either way.
Saved in this browser only.