You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The problem happens when you reference a large set of deeply nested third-party packages that all have common dependencies. When you run dotnet nuget why Microsoft.CodeAnalysis.NetAnalyzers, and get 47,088 lines of output, there's a need for a simplified view.
Skimming this 47k lines in a few places tells me that the package in question is coming from a morass of third-party packages. Now that I know that, I'm left with two questions:
How many of the third-party packages are directly referencing Microsoft.CodeAnalysis.NetAnalyzers, so that I can report them all to the vendor? Skimming 47k lines of output to answer this question is not realistic.
Are there any other packages besides these third-party packages that also may be causing Microsoft.CodeAnalysis.NetAnalyzers to be referenced? Again, I saw pages flashing by, but I can't be sure that I'm not missing something, and I can't skim 47k lines. I could try to recreate an empty solution structure with only package references and no source files, and try removing this vendor's packages from every project in the solution and running dotnet nuget why again, but that's not nice and quick either.
To address this situation, please consider providing an option that can be used to limit the output so that it displays only the immediate parent packages that bring in the queried package, once per project and target. The output will not explain why the parent packages were included, and this is by design.
As a starting point for design, I would suggest an ancestor depth parameter, so perhaps --depth 1 would provide what I'm requesting here, but --depth 2 might explain all the unique ancestry paths up to two steps removed from the queried package. --depth 2 would still include any one-step-deep paths directly back to the project, with a single intervening parent, as well as any direct references back to the project with no intervening parent.
Motivating image
This is 1/850th of the output. A lovely fractal pattern, which will deduplicate beautifully with a --depth limit option:
The text was updated successfully, but these errors were encountered:
Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue!
If you believe this issue was closed out of error, please comment to let us know.
The problem happens when you reference a large set of deeply nested third-party packages that all have common dependencies. When you run
dotnet nuget why Microsoft.CodeAnalysis.NetAnalyzers
, and get 47,088 lines of output, there's a need for a simplified view.Skimming this 47k lines in a few places tells me that the package in question is coming from a morass of third-party packages. Now that I know that, I'm left with two questions:
How many of the third-party packages are directly referencing
Microsoft.CodeAnalysis.NetAnalyzers
, so that I can report them all to the vendor? Skimming 47k lines of output to answer this question is not realistic.Are there any other packages besides these third-party packages that also may be causing
Microsoft.CodeAnalysis.NetAnalyzers
to be referenced? Again, I saw pages flashing by, but I can't be sure that I'm not missing something, and I can't skim 47k lines. I could try to recreate an empty solution structure with only package references and no source files, and try removing this vendor's packages from every project in the solution and runningdotnet nuget why
again, but that's not nice and quick either.To address this situation, please consider providing an option that can be used to limit the output so that it displays only the immediate parent packages that bring in the queried package, once per project and target. The output will not explain why the parent packages were included, and this is by design.
As a starting point for design, I would suggest an ancestor depth parameter, so perhaps
--depth 1
would provide what I'm requesting here, but--depth 2
might explain all the unique ancestry paths up to two steps removed from the queried package.--depth 2
would still include any one-step-deep paths directly back to the project, with a single intervening parent, as well as any direct references back to the project with no intervening parent.Motivating image
This is 1/850th of the output. A lovely fractal pattern, which will deduplicate beautifully with a
--depth
limit option:The text was updated successfully, but these errors were encountered: