NuGet Package Restore ↔ Git Source Control: Deterministic Build Interoperability

NuGet Package Restore ↔ Git Source Control: Deterministic Build Interoperability

NuGet 4.8+ provides the packages.lock.json file to capture exact versions of direct and transitive dependencies. When committed to Git, this file allows dotnet restore to ensure that every developer and CI agent uses the same dependency graph, preventing issues where floating version ranges resolve to different patch versions across environments.

A challenge arises when the infrastructure surrounding the lock file changes. Because the lock file encodes the specific source URLs used during its creation, there is a tight coupling between the committed lock file and the nuget.config file. This creates uncertainty when migrating feeds or updating internal mirror URLs.

To verify repeatability, a clean workstation environment—where the %userprofile%\.nuget\packages folder is deleted—is typically used to ensure the restore process relies solely on the lock file and configured feeds.

The following points remain unresolved regarding this integration:

• If a package source URL in nuget.config is updated after a lock file is committed, does dotnet restore fail due to the source mismatch in the lock file, or does it resolve the locked version from the new URL?
• When a feed is replaced by an external mirror, does the restore process prioritize the locked version regardless of the source change, or is a lock file regeneration required?
• Does the presence of a committed lock file guarantee binary identity in a CI pipeline that clears the global cache, provided the feed metadata remains constant?