Bug

Fixes: NuGet/Home#13752
FIxes: NuGet/Home#14695

Description

Shows the requested and resolved versions for each package. Removes the version for project references, making it more obvious that the graph node is indeed a project.

The above feature modified the same lines needed to fix running why on a legacy csproj, so both are being fixed in the same pull request, rather than two PRs that would need to be opened sequentially.

I used copilot to implement showing the requested version, but when reviewing its changes to DependencyGraphFinder.cs, I found the file's algorithm confusing. So, I commit copilot's changes unreviewed, then rewrote the class from scratch, with a few small changes in other files. Overall, it reduces product code by about 100 lines. If my rewrite isn't liked, we can revert the refactor commit from the branch, but then if someone has questions about the changes to DependencyGraphFinder, I may not be able to answer it.

The algorithm of the new class is, for each target in the assets file, create an in-memory LockFileTargetLibrary with the project's direct package and project references as dependencies, then recursively convert a LockFileTargetLibrary into a DependencyNode. It does this with no intermediate state, other than the "fake" LockFileTargetLibrary for the project's root. The tree is filtered for the package requested on the dotnet package why command line, but the way it's written, it will be trivial (change one if statement) to either show the complete unfiltered tree, or filter on multiple packages, or a partial package id match.

The implementation has a performance optimization, so it doesn't create the tree/graph and then filter as a second step. Instead, it returns nulls when the package is filtered out and there are no children. Dependencies that return null are removed, so when no dependency has the package, the node looks like it has no dependencies and so also gets removed if the package name also doesn't match. So, entire subtrees that don't contain the searched requested package avoid being created, with minimal (hopefully zero) memory allocations.

In order to have stronger guarantees on nullability, I modified DependencyNode to be an abstract class so PackageNodes must have both a requested version and resolved version.

The refactor found some tests that use an invalid assets file. I deleted these tests as the multi-rid nature of the tests are very difficult to replicate, but mostly test scenarios that theoretically possible, but not really practical. I'll comment on the two assets files explaining which each is infeasible, as justification why to delete the test rather than spending a lot of effort to fix it.

PR Checklist

• Meaningful title, helpful description and a linked NuGet/Home issue
• Added tests
• Link to an issue or pull request to update docs if this PR changes settings, environment variables, new feature, etc. update dotnet nuget why docs with requested version information Home#14697