NuGet Package Restore ↔ Git Source Control: Deterministic Build Interoperability

Answer

When a packages.lock.json file is committed, dotnet restore treats the recorded source URLs as metadata only; the decisive factor is the content hash (SHA512) stored for each package.

1. Updated source URL in nuget.config

Confirmed fact: The restore does not fail because the URL differs. It attempts to download the exact version from any configured source that provides a package whose hash matches the lock file entry. If the hash matches, the restore succeeds; if the package is missing or the hash differs, restore fails with a hash‑mismatch error (NU1004).

Likely explanation: If the new feed hosts the same binary (identical hash), the lock file remains valid and no regeneration is needed. If the feed offers a different build of the same version, the hash will mismatch and restore will abort, signalling that the lock file must be regenerated.

2. Feed replaced by an external mirror

Confirmed fact: The lock file guarantees the version and hash; the source URL is only a hint. When the mirror serves byte‑for‑byte identical packages, dotnet restore --locked-mode will succeed without touching the lock file.

Likely explanation: Should the mirror differ (e.g., rebuilt package, different dependencies), the hash check fails and restore will error. In that case you must regenerate the lock file against the new mirror.

3. Binary identity in CI with cleared global cache

Confirmed fact: Using dotnet restore --locked-mode after clearing the global package cache (dotnet nuget locals all --clear) yields bit‑for‑bit identical outputs as long as every configured feed returns packages whose hashes match those stored in the lock file.

Likely explanation: If any feed returns a package with a different hash (even same version), restore will fail in locked mode, preventing silent drift. Without --locked-mode, NuGet may update the lock file if version ranges allow, which could change the resolved graph.

Verification steps for your environment

1. Commit the current packages.lock.json to Git.
2. On a clean workstation, run dotnet nuget locals all --clear (or delete %userprofile%\.nuget\packages).
3. Update nuget.config with the new feed URL (or add a packageSourceMapping entry).
4. Execute dotnet restore --locked-mode.
5. If the command succeeds, compare the output binaries (e.g., via dotnet build and checksum) with a baseline build; they should be identical.
6. If it fails with a hash‑mismatch error, the new feed does not provide the exact same package; you must regenerate the lock file (dotnet restore without --locked-mode then commit the updated lock file).

One diagnostic detail that would change the recommendation is whether the new feed supplies packages with the exact same SHA512 hashes as recorded in the lock file. If you can confirm hash equality, no lock‑file regeneration is required; otherwise, you must regenerate.