Limits of NuGet floating version ranges for zero‑downtime migration

Direct answer

Using a floating range like 1.0.* does not make the build non‑deterministic by itself; NuGet resolves the range to the highest compatible patch at restore time and writes that exact version into the lock file (project.assets.json). If the lock file is regenerated on every deployment, the selected patch may change and could introduce a breaking update, jeopardising zero‑downtime guarantees. To keep the migration safe, commit the lock file and use it exclusively for all environments, or generate the lock file once in CI and then treat it as immutable.

Confirmed facts

• NuGet treats 1.0.* as “any version with the same major/minor, highest patch at restore time” (research).
• The exact version chosen is stored in the lock file; as long as the lock file is not changed, all instances receive the same version, enabling side‑by‑side execution.
• Pre‑release versions are excluded from a floating range unless the range explicitly includes them (e.g., 1.0.*‑*).
• In .NET Framework projects, assembly binding redirects are required for multiple versions to coexist; otherwise the CLR may load only the first version found.

Likely explanation

If your CI pipeline runs dotnet restore (or nuget restore) on every build/deploy, the floating range is re‑evaluated each time. A newly published patch that satisfies the range will be selected, potentially changing the runtime version between the old and new instances during a rolling update. When that patch contains a breaking change, the older instance may fail with MissingMethodException or TypeLoadException, breaking the zero‑downtime guarantee.

Steps to achieve predictable, zero‑downtime upgrades

1. Define dependencies with a floating range (e.g., 1.0.*) in .csproj to allow automatic patch selection during the initial lock‑file generation.
2. Run a restore once in your CI pipeline to create project.assets.json. Inspect the file to confirm the exact patch version that was chosen.
3. Commit the lock file to version control and do not run restore again** on subsequent deployments; instead, use the locked version for all builds.
4. When you want to move to a newer patch, manually update the lock file (by running restore again) after verifying the new patch is backward‑compatible (e.g., via API‑compatibility tests). Then redeploy using the updated lock file.
5. For .NET Framework projects, add the necessary assemblyBinding redirects in app.config or web.config to allow both old and new versions to load side‑by‑side during the migration window.

Missing diagnostic detail: Do you currently regenerate the lock file on each deployment (i.e., run restore every time), or do you rely on an existing committed lock file? Knowing this will confirm whether the floating range is being re‑evaluated and thus whether the lock‑file‑only approach is needed.