NuGet dependency resolution limits: nearest wins behavior

When restoring a .NET project, NuGet resolves dependencies by selecting the nearest version in the dependency graph. This “nearest wins” strategy can cause subtle version conflicts, especially when transitive dependencies diverge.

Project assets are recorded in the lock file (project.assets.json) to enforce reproducibility. However, the interaction between the nearest wins rule and lock file locking is not fully documented, leaving teams uncertain about version consistency across a solution.

Specifically, the goal is to understand whether the lock file can override the nearest wins decision when a top‑level package requires a higher version of a shared library, and under what circumstances this override applies.

Questions:

• What exact conditions trigger the nearest wins rule when multiple paths to the same package exist?
• Does the lock file guarantee that the resolved version is the same across all projects in a solution, even if nearest wins would normally pick a different one?
• Are there documented scenarios where a higher explicitly required version can override nearest wins, and how is that behavior controlled?