Home: NuGet pack's minimal dependency set could potentially break stuff

[chrischu]

I just found out that using NuGet pack only references a minimal set of package dependencies in the generated package file.

Lets say I have a project Project.csproj that I use as input for NuGet pack to create a Project.nupkgpackage. Let's also say that Project.csproj has two NuGet references to Package.1.2.3 and References.Package.1.0.0, where the References.Package.1.0.0 also depends on Package with a minimum version of 1.2.0 ([1.2.0, 2.0.0)).

Now when creating the Project.nupkg file only the References.Package.1.0.0 package is recorded as a reference.

When creating a new project and referencing Project.nupkg via NuGet, the Package is also installed as expected. What is unexpected however is, that it is installed in version 1.2.0.

This essentially means that as an author of Project.csproj I have to be aware that potential users of my NuGet package might have different versions of Package and therefore if I find a bug in Package and decide to upgrade to a newer version and release a new version of my NuGet package, my users could still run into the same bug.

Therefore it would be nice if there was a switch (or something similar) to disable this minimal set optimization when calling NuGet pack.

By the way: I am aware that I can circumvent this issue by explicitly specifying my dependencies in a .nuspec file, however this would be a significant added maintenance effort and it would be much simpler to just use NuGet's automatic behavior without the minimal set optimization.

[yishaigalatzer]

The optimization is important because long term you want to just reflect your dependencies, and not the transient dependencies that might drop off, particularly if your package is going to get consumed in a project.json scenario, you really want just the top level dependency AND you need to explicitly upgrade if you need a minimum newer version of the dependencies.

For your scenario I wonder what version of package you had installed, you don't show what it is? Did pack miss the fact that you used a newer version in your project?

[chrischu]

In my scenario the installed version of Package is 1.2.3, and yes, it very much looks like pack misses the fact that I used version 1.2.3.

Maybe the solution would be not to dismiss set optimization entirely, but adapt it to take actual version into account. Basically when pack processes the package dependency on References.Package it needs to realize that the minimum version referenced by References.Package (1.2.0) is older than the version actually referenced (1.2.3) and probably add an explicit reference to Package.1.2.3 to the resulting NuGet package.

[yishaigalatzer]

Yes! Totally agree

[Tasteful]

Another side with the minimal package dependency optimization is that if you example referencing Microsoft.AspNet.SignalR.Core and Microsoft.AspNet.SignalR.Owin that will create a nupkg that only Microsoft.AspNet.SignalR.Owin is as dependency. If the owner of Microsoft.AspNet.SignalR.Owin package decide to remove the dependency to Microsoft.AspNet.SignalR.Core and publish a new version any installation that will install my package with highest dependency (before I repack my package) will missing the package reference to Microsoft.AspNet.SignalR.Core and need to install that manually.

[yishaigalatzer]

That is definitely the right approach rather than added core explicitly. For example if the signalr team decided to replat owin on something different you should pick that and not have stale dependencies flow through.

For sure there is no 100% right answer, but in general flattening dependencies is the less favorite pattern to go with for any package author.

[Tasteful]

If we look at the new xproj/project.json dependencies is both direct referenced in project.json and indirect referenced from another package. I haven't check the nupkg created with direct references if they are included/excluded if the same package is indirect referenced, maybe something similar in the old packages.config. Example adding all the indirected references as development-dependency and always include all referenced packages that not is development-dependency in the nupkg, then the package author get more flexibility how the dependency chain should be created.

[yishaigalatzer]

@Tasteful let me expand a bit on what you wrote

If we look at the new xproj/project.json dependencies is both direct referenced in project.json and indirect referenced from another package.

The main difference between packages.config and project.json scenarios is where the package graph resolution happens. In packages.config it all happens at install time and the packages.config contains the flattened out list. The user is not expected to hand edit the package list or versions inside the file. In project.json the user can and in many cases encouraged to edit the file manually.

Typically in the project.json world, you define things you depends on directly (similarly to how you install a package from the UI), and then you may specify secondary dependencies where you want to explicitly control the version of the package.

I haven't check the nupkg created with direct references if they are included/excluded if the same package is indirect referenced, maybe something similar in the old packages.config

The algorithm for project.json is documented here: https://docs.nuget.org/consume/projectjson-dependency

then the package author get more flexibility how the dependency chain should be created.

Yes once you define the package dependencies in project.json, the story is a lot clearer. NuGet pack doesn't have to guess your intent and minimize the package list. Think about project.json as your nuspec written in json

[TimBarham]

Should be fixed by fix for #338.

[chrischu]

Wait a second, Issue #338 states that it should be fixed by fixes for THIS issue...

That seems like a bit of an infinite "wontfix" loop :(.

[toddm]

This was actually fixed by https://github.com/NuGet/Home/issues/759

[chrischu]

Ok cool! Looking forward to the next release then!

[TimBarham]

Oops, sorry for the confusion!