Your dependency tooling asks one question: does it restore?
Restore is a constraint solver. It reads version numbers, checks the arithmetic, and reports success. It never opens a package. It has no opinion on whether the versions you declared make sense together.
So this passes:
$ dotnet restore
Restored in 3.2s.And this is what was actually in the box:
$ redecker inspect SQLitePCLRaw.lib.e_sqlite3 --from 2.1.11 --to 2.1.12
error RDK0001: buildTransitive/net461/…targets references
runtimes/win-arm/native/e_sqlite3.dll, which the package does not contain
warning RDK0002: drops 5 runtime identifiers: win-arm, win10-arm, win10-arm64, win10-x64, win10-x86That upgrade cost a CI round, a red pull request and a revert commit. Redecker found it in about a second, from metadata, before any of that.
dotnet tool install --global dotnet-redecker # investigate an upgrade
dotnet add package Redecker.MSBuild # fail the build insteadNot an updater. Not a replacement for dotnet restore. Not a resolver.
It answers one question those tools structurally cannot: is this upgrade sound in ways that restore succeeding does not prove?
Where .NET 10's package pruning overlaps with it, use pruning — it happens inside restore, which beats anything bolted on. The comparison is honest about exactly where that line falls, and about the one thing no tool here can help with: epochs.