26

Closed

Package dependencies resolve improperly across Package Sources

description

Duped by http://nuget.codeplex.com/workitem/862

While using the Add Library Package Reference dialog, selecting a package source and installing a package from that source which relies on a package from another source throws an error message: "Unable to resolve dependency '[remote Package name]'"

Steps to reproduce:
1) Create a custom repository (whether file or web based seems to be irrelevant)
2) Add a custom package to the custom repository which depends on a package from another repository. e.g. [MyRepository: MyPackage] depends on [NuGet official repository: Newtonsoft.Json]
3) Open the Add Library Package Reference Dialog
4) SELECT YOUR CUSTOM REPOSITORY (this part is important)
5) Select your custom package and click Install

Workaround
If you instead select "All" as your package source, and then search for your package everything works fine! This seems to be some kind of "scope" issue within the dialog itself. i.e. the package manager seems to be ignorant of anything outside of the selected Package Source
Closed Jun 1, 2011 at 8:18 PM by bhaveshc
Verified that if a package has dependency on other packages contained in different repository, it resolves it and install works. Checked with both dialog and console. If there are multiple versions available, it doesn't honor the source order but instead picks up the most optimum version (next higher major with highest minor) from any of the sources added.

comments

dotnetjunky wrote Jan 24, 2011 at 6:21 PM

This is by design. If you select a specify Package Source, NuGet only search for dependencies within that source.

If you want NuGet to search across all sources, you have to select All.

jesschadwick wrote Jan 24, 2011 at 6:26 PM

This is not the behavior I would expect, though. I can understand if dependencies within that source get preference (that would be expected), but to not resolve at all provides a poor experience.

I'd expect one of two things:
1) try to resolve within the selected source, but fall back to all sources
2) allow package creators to (optionally) specify which package source a package lives in

Either way (or even another way I haven't considered), I'd expect my dependency to be resolved somehow.

Haacked wrote Jan 25, 2011 at 9:33 PM

Interesting idea. Is there a reason you don't simply want to use the "All" node? If the reason is you want the explicitly chosen package to be from a specific feed, the All Node gives preference in the order that the package sources are specified.

jesschadwick wrote Jan 25, 2011 at 10:59 PM

It's a semantic thing. The Package Manager seems to try to follow the UI patterns in the rest of Visual Studio. The best example/comparison would be the left nav pane in the New Project or New Item dialogs - they are for filtering your choices by category and do not serve any functional purpose. The relative example of this NuGet issue in the New Project dialog would be if my New Web Project had a dependency on WCF Data Services, but since I don't have the Data category selected in the left nav, VS throws an error instead of creating my project with the proper reference added.

In other words, I expect the Package Sources list in the Library Package Manager dialog to simply filter the displayed packages, not affect the functionality of actually installing a selected package. In effect, the state of the UI changes the definition of the package, which is awkward.

BrianLewisICS wrote Feb 18, 2011 at 5:54 PM

We have a custom source internally in my organization; since we only have a couple of packages it's faster for developers to click on our feed to get to our packages than to click on All and scroll through or type search text to find the package they want. However, since our package depends on Unity, we either have to include the Unity package in our custom source, or tell developers not to click on our org's package source when installing our packages.

Either of jesschadwick's proposals would work in my situation; option 2 (allow package creators to specify a package source) is what I would prefer, since it would mean the package creator would have to explicitly say "I want to override NuGet's default behavior of only resolving dependencies from the selected package source. Even simpler would be for the only options to be "Search All Package Sources" or "Search the Current Package Source" (default) so that NuGet doesn't have to figure out how to resolve source names/paths as part of the process. The "Search All Package Sources" option would behave as though the user had clicked the "All" tab in the current version of NuGet; the default option would keep the existing behavior of only searching the current source for the dependency.

mrchief wrote Feb 23, 2011 at 5:44 PM

this design is not adequate. it results in poor user experience and it forces users to select All and perform search.

valentinedwv wrote Mar 9, 2011 at 8:51 PM

You should be allowed to specify which repositories to check (aka maven like).

Dependencies should allow you to specify sources, so you can pull packages for testing, well, packaging

cthames wrote Apr 18, 2011 at 8:20 PM

@Haacked: The "All" node doesn't seem to work. I have 3 packages on a network share "\server\NuGet". I can Get-Package -Remote and return all 3 packages (A, B, C). Package A has no dependencies and can be Installed just fine. However if I try to install package B or C which depends on package A, I get "Install-Package : Unable to resolve dependency 'A (>= 1.0.0)'". Note: In my case a 3 packages reside in \server\NuGet and do not depend on any outside Package. However still the "All" or even the specific package source of "\server\NuGet" returns that same error "Install-Package : Unable to resolve dependency 'A (>= 1.0.0)'"

dannytuppeny wrote May 2, 2011 at 3:50 PM

I came across this issue too, while building/testing the second version of a package locally. Selecting "All" doesn't work, because:
  1. If the official feed has higher priority then the search results only showed the "live" version of my package, and not the more recent version from my local folder, so I couldn't install it to test
  2. If my local folder has higher priority then the dependency is not resolved properly (I require a package from the live feed).
I think the most flexible option would be to prompt the user, saying "Hey, this package has dependencies that could not be found in the selected feed - would you like to check the other feeds to resolve these dependencies?"

sgisbert wrote May 4, 2011 at 11:04 PM

This is a basic feature for me, and doesn't seem so hard to solve.

We have several private packages with dependencies with Enterprise Library, so we ended up copying the official packages to the local feed, which becomes into a redundant, hard-to-mantain scenario. It seems quite easy to look for dependencies in the "all" feed if they cannot be resolved in the selected feed, or let the developer specify the source in the <dependencies> tag at the .nuspec file.

pranavkm wrote May 20, 2011 at 6:05 PM

Fixed with changeset: 108b8c457d94

bhaveshc wrote May 31, 2011 at 11:03 PM

If my understanding is correct, in order to install the dependencies, it will follow the order in which sources are specified. In my case, that's not what I am seeing. I have a local folder with jquery.validation(1.8.0.1) with dependency jquery >= 1.3.2. There is jquery (1.6.1) in the same folder. I have listed this source to be the first in the list of package sources. With package manager, when I try to install jquery.validation, it installs jquery 1.4.4 (supposedly from official source which is listed 2nd)

If I remove the official source altogether, it correctly installs jquery 1.6.1 from the same local folder.

Steps:

  1. Put jquery 1.6.1 and jquery.validation 1.8.0.1 in some local folder and add it in the list of package sources
  2. Move this source up so that it's first in the list
  3. With package manager, select this local folder under online tab and install jquery.validation

Expected:

jquery 1.6.1 contained in the same folder should be installed while resolving the dependency.

Actual

It installs jquery 1.4.4 supposedly from official source

dfowler wrote Jun 1, 2011 at 1:32 AM

That behavior is by design

drewmiller wrote Jun 1, 2011 at 6:46 PM

If I understand things correctly, by design, it will first try to resolve dependencies using the same source as the package being installed. If it doesn't find the dependency, it will try the configured sources in order. We need to make sure that dependencies are resolved across sources when the dependency isn't in the same source as the package being installed.

shravanpamani wrote Oct 25, 2011 at 8:02 PM

I still get this issue. can you help me how to resolve this. It installs my package if I select 'All' which is real pain, as there are plenty available online and I have to search for my package till the first alphabet of my package name.

dfowler wrote Oct 26, 2011 at 8:20 AM

@shravanpamani this has been fixed for a while. Update your version of nuget.

shravanpamani wrote Oct 26, 2011 at 6:02 PM

@ dflower i just downloaded both NuGet and Nuget Package Manager 3 days ago.. this is the my first installation of Nuget on my machine. but still have the same issue.

shravanpamani wrote Nov 1, 2011 at 2:26 PM

@ bhaveshc & @ dflower i still have issue, my package does not install when i select the local repository, it fails at installing dependency 'Unity'. It goes well when i select 'All' option . I updated Nuget, can you help me out?

pranavkm wrote Nov 1, 2011 at 4:21 PM

Could you give us a sample package where the problem repros? Might help since dependency resolution does work fine across sources for me.

Sign in to add a comment