Restore Pipeline
Run `dotnet build` and the compiler is the second thing that happens, not the first. Before one line compiles, a separate step has already walked your packages, picked exact builds, and written them to disk.
- ▸
dotnet buildcompiles second, not first: a separate step picks and writes every package build before compiling. - ▸Deleting
obj/barely slows the next build; deleting~/.nuget/packagesdoes, because only one cache holds the downloaded bytes. - ▸A second build with no edits is near-instant: a matching graph hash skips the work, leaving
6.0.*stale.
Type dotnet build and it feels like one action. It is two. Before the compiler sees a single .cs file, a separate step runs to completion: it reads which packages the project asks for, picks one concrete build of each, and drops the answer on disk. Only then does compilation start. You can run that step on its own with dotnet restore, and three other commands reach the very same code: nuget restore, msbuild -t:restore, and the Restore command inside Visual Studio. dotnet build and dotnet run simply call it for you first. Four doors, one room. Skipping it is not optional; the compiler has nothing to reference until that step has written its output.