joelverhagen
commented
2 years ago Doing a full, recursive dependency check is a very hard thing to get right for NuGet.org, partly due to scale issues and party due to feasibility.
Actual, resolved transitive dependencies for a top-level (direct dependency) package can change greatly from project to project due to the "diamond dependency" problem and NuGet restore's lowest application version rule. In other words, that System.Reactive 5.0 version may not always be the resolved version in a consuming project. It could actually be a higher version of that package with different compatibilities (supported frameworks added or removed).
Another possible perspective here is that the ReactiveProperty 8.0.3 has a discrepancy in it's packaging. I might be mistaken here but I am confused on how this package was even produced. When running project restore, build, and pack on this "ReactiveProperty" project itself, I imagine restore would fail for the .NET Framework 4.6.2 target since it would fail to resolve this System.Reactive dependency. My guess is that the project owners have a non-standard NuGet pack flow.
I see this issue on the ReactiveProperty GitHub repo. Perhaps look into that as well: https://github.com/runceel/ReactiveProperty/issues/330
Related Problem
Recently I had a problem with ReactiveProperty 8.0.3 package, in documentation it said to support .Net Framework 4.6.1 (in fact nuget.org say the same right now), but it have a dependency in System.Reactive 5.0 wich in fact only support .Net Framework 4.7.2 and above. Then after upgrade everything fail in my WPF .Net Framework 4.6.1 project.
The Elevator Pitch
I think nuget should check full dependency graph to really detect the real minimun framework required for a package.
Additional Context and Details
No response