Locked vs. Unlocked NuGet Restore: Choosing Determinism for CI/CD Pipelines

Goal

Establish a repeatable .NET dependency resolution strategy that behaves identically across developer machines and CI agents.

Constraints and Uncertainty

The .NET SDK supports dotnet restore --locked-mode, which reads a committed packages.lock.json and fails if the resolved graph differs. This prevents silent transitive-version drift but introduces friction: lock files must be regenerated on every PackageReference or NuGet.config change, merge conflicts arise in active repositories, and older SDKs lack the feature entirely. Unlocked restore tolerates drift but sacrifices determinism. Private feeds add another failure mode when locked restore references packages unavailable to the CI agent.

Questions

1. At what team size or change frequency do lock-file merge conflicts outweigh the determinism benefit?
2. Should the CI pipeline enforce locked restore on every build, or only on protected branches?
3. How do you handle SDK version mismatches between developer machines and build agents when locked mode is required?