A .NET Docker build is slow and rebuilds restore layers after almost every source edit. How would you improve it without making the image unreliable?

Docker build context, layer caching, and reproducible .NET builds

Builds deterministic images efficiently by controlling context, restore layers, dependency inputs, and cache invalidation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would keep the build context small with .dockerignore, then copy solution, project, and dependency files before running dotnet restore. Source files are copied afterward, so a code-only change can reuse the restore layer. I would include every file that affects restore, such as NuGet.config, Directory.Build.props, Directory.Packages.props, and lock files, so the cache is fast without becoming stale.

Full answer below

Practice focus

Build context, .dockerignore, Docker layers, project files, dotnet restore, locked dependencies, cache invalidation, and CI caches.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Docker reuses an instruction only when that layer and its inputs still match. The order of COPY and restore steps determines whether an ordinary source edit invalidates the expensive dependency layer.
I would keep the build context small with .dockerignore, then copy solution, project, and dependency files before running dotnet restore. Source files are copied afterward, so a code-only change can reuse the restore layer. I would include every file that affects restore, such as NuGet.config, Directory.Build.props, Directory.Packages.props, and lock files, so the cache is fast without becoming stale.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
A multi-stage build keeps SDK and compiler artifacts out of the runtime image. In CI I can use BuildKit cache mounts or a remote cache, but the build must remain correct when the cache is empty. I pin the SDK through the build image and use controlled package sources and locked dependency versions where the project requires repeatability. Secrets for private feeds use build-secret mechanisms and must not appear in Dockerfile arguments or persisted layers.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Copying the whole repository before dotnet restore.
Leaving bin, obj, and local secrets in the build context.
Assuming CI cache is required for correctness.
Passing feed credentials through ARG values.

A .NET Docker build is slow and rebuilds restore layers after almost every source edit. How would you improve it without making the image unreliable?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement