Dependency Resolution

NuGet picks the lowest version that satisfies a range, not the highest. Ledgerline.Rates asks for Ledgerline.Money >= 1.2.0; the feed has no 1.2.0, so the lowest version above it, 1.5.0, is chosen — with a warning, because the package author’s minimum was never tested:

Picking the lowest keeps restores stable: publishing Money 3.0.0 tomorrow does not change today’s graph.

Source: Lowest applicable version.

A floating version (1.*, *-*) is the exception: it resolves to the highest match (Package Versions and Ranges).

Source: Floating versions.

A version the project references directly wins over any transitive request — even a lower one. With Ledgerline.Fx (needs Money >= 2.0.0) and a direct Ledgerline.Money 1.0.0:

The direct 1.0.0 won, and the SDK reports the downgrade as an error — NU1605 is in the SDK’s default WarningsAsErrors even though TreatWarningsAsErrors is off — because Ledgerline.Fx may call APIs that 1.0.0 does not have. Raise the direct reference (or remove it). Direct references are also how a consumer upgrades a transitive package, for example to a version with a security fix.

Source: Direct dependency wins.

When two packages need different ranges of the same package, NuGet picks the lowest version that satisfies all of them. Ledgerline.Fx needs >= 2.0.0 and Ledgerline.Rates >= 1.2.0:

No warning: 2.0.0 is inside both ranges. dotnet nuget why shows why a transitive package is there:

With NuGet 7.9.0 the command printed nothing, with exit code 0, when its output was redirected to a file or a pipe; the tree above was captured through a pseudo-terminal (script -qc "dotnet nuget why …" /dev/null). In CI logs, use dotnet package list --include-transitive instead, which does print when redirected (but does not show the paths).

Source: Cousin dependencies, dotnet nuget why.

Ledgerline.Fx 1.0.0 needs >= 2.0.0, Ledgerline.Tax needs [1.0.0,2.0.0) — no version satisfies both. The resolver chose 2.0.0 and warned:

Even two exact requirements — Ledgerline.Fx 2.0.0 needs [2.0.0], Ledgerline.Audit needs [1.0.0] — gave only NU1608 with the default resolver:

The same restore with the legacy resolver (-p:RestoreUseLegacyDependencyResolver=true) failed with the documented version-conflict error:

NuGet rewrote the resolver for performance in 6.12 (.NET 9) and documents the new one as "functionally equivalent"; here it was not: the old one stopped with an error, the new one restored with a warning. Treat NU1608 as seriously as NU1107 — one package is now running against a dependency version its author excluded. The fixes are the same: reference the dependency directly at a version both packages accept, upgrade the package with the narrow range, or drop one of them.

Source: NuGet dependency resolver, Resolving incompatible package errors, Version ranges and prerelease versions.

Ledgerline.Legacy contains only lib/net48/. A net10.0 project still restores it, through the default AssetTargetFallback, and warns:

The library is .NET Framework code: it may load and work, or fail at run time when it touches an API .NET does not have. Look for a version of the package with a netstandard2.0 or net8.0+ build.

Source: AssetTargetFallback.

A range only matches a prerelease when the range itself contains a prerelease bound (2.1.0-*, >= 2.1.0-beta.0) or floats with *-*; a dependency on >= 2.0.0 never selects 2.1.0-beta.1. Which parts of a resolved package flow to the project and to its consumers is controlled separately with IncludeAssets, ExcludeAssets and PrivateAssets (PackageReference).

Source: Managing dependency assets.