.NET 10 NU1510 package pruning can turn an SDK upgrade into a failed restore when a repository promotes warnings to errors. The tempting fix is to delete the named PackageReference everywhere.
That is safe for a net10.0-only application when the framework supplies the assembly, but it can break a library that still targets netstandard2.0. I treat NU1510 as a target-specific dependency decision: prove where the reference is redundant, retain it where it is required, and verify the package produced for consumers.
Why NU1510 becomes a CI failure
Beginning with .NET 10, package pruning is enabled by default for projects targeting .NET 10 or later. NuGet raises NU1510 when a direct reference to a package registered for pruning can be completely removed because the targeted SDK supplies the same or a higher assembly version.
The NU1510 diagnostic reference is precise about that boundary. This is not a general-purpose unused-package detector, and it does not apply automatically to arbitrary third-party packages.
