Hello all, I did search for this but I didn't find answer. It might be stupid question because I am not really expert on nuget packages. But can you please explain why did you put dependencies for example for .NET standard 2.0:
When you check dependencies for Nuget package Microsoft.Win32.Registry there is dependency for System.Memory again. Why do you need to put dependency System.Memory in list when Microsoft.Win32.Registry is already depending on System.Memory?
Thank you all for your inputs
I think it is because System.Memory 4.5.1 is required (otherwise 4.5.0 would be used)
Make sense @ErikEJ and what about System.Buffers? When I check Microsoft.Win32.Registry (4.5.0) I see dependecy on System.Buffers (>= 4.4.0). And yet Microsoft.Data.SqlClient has System.Buffers (>= 4.4.0) listed separately. Any idea why?
A bug/mistake ?
I had a wild theory that if you load your package only with listed dependencies without next level dependencies, it would work. Basically cutting out all rubbish you don't use from chained tree namespaces-dependencies. Could it be something near true?
No. There may be some dependencies which aren't used in specific usage patterns but in general it isn't a sensible idea to omit dependencies and expect something to work. Nuget should restore the dependency graph for you when you compile the project.
You should define any direct dependencies your project has in the nuget regardless of any indirect dependencies. You can't rely on indirect dependencies that might change in future versions of your dependencies.
Hi @MartinHBA
Do you have any further questions, or can the issue be closed?
I am trying to figure it out eventually why in my example I cannot run this in PowerShell Core
Install-Package Microsoft.Data.SqlClient -Provider nuget
which will result in "dependency loop error"
only way I can do it is with
Install-Package Microsoft.Data.SqlClient -Provider nuget -skipdependencies
and there I am afraid I might be missing some functionality.
Looks like Package manager for NuGet in PowerShell is the culprit.
I am glad for your guidance and help.
I think issue is PowerShell Nuget implementation, nothing wrong with dependency tree in general