"List" shows correct version of a package, but "Install" can't find it

Oct 11, 2011 at 6:30 PM

I am trying to use the NugetPowerTools to automatically install required packages prior to build, but it keeps complaining that it can't find the required package. Running the commands manually (see below) shows that List is able to find the package, but Install is not. The package source named "Internal" points to a mapped drive where our packages are located. I also tried substituting that path directly as the source, but that did not work for either command (it used to work for List but not Install in a previous revision of 1.5, but it appears that in the most recent version, List can only take named sources, not paths).

Any ideas?

update -self
Checking for updates from https://go.microsoft.com/fwlink/?LinkID=206669.
Currently running NuGet.exe 1.5.21005.9019.
NuGet.exe is up to date.

list -source "Internal"
Cclp.Core 1.71.6687
Cclp.Data 0.1.4007
Cclp.Logging 1.20.5810.1
Cclp.Logging.Log4Net 1.20.5810.1
Cclp.Presentation 1.24.6359
Cclp.Presentation.Telerik 1.24.6359
Cclp.ServiceModel 1.6.5964.9

install PortwareAdapter.WebService\packages.config -source "Internal" -o packages
Unable to find version '1.71.6687' of package 'Cclp.Core'.

Oct 11, 2011 at 8:05 PM

if you do nuget -list Cclp (not specifying the source) do you see your packages?

NuGet.exe should use the sources configured in %AppData%\NuGet\NuGet.config so if it's in there it *should* just work.

Oct 11, 2011 at 8:57 PM

Yes, running List without specifying a source does find the packages. Running Install without specifying a source does not.

Oct 11, 2011 at 9:04 PM

So it sounds like you're saying that Install doesn't work whether you specify the source or not. Correct? It's supposed to work, so I'm not sure what's going on. Maybe try running fiddler while doing it to look at the requests being made.

Oct 11, 2011 at 11:53 PM

Yes, that's correct. It DOES work if I install a project from the official Nuget feed, for example Castle.Windsor; but NOT for any package on our network share. I can also still install internal packages using the Package Manager in Visual Studio; it seems to only be the Install command using the Nuget command line that isn't working correctly.

Is there any way to get diagnostic information from the running command? A -verbose switch might be useful. I will try to use Fiddler to sniff the UNC traffic.

Oct 12, 2011 at 12:24 AM

Is your source UNC or http? If UNC, then fiddler won't help.

The fact that you can install from VS but not from nuget.exe is very puzzling, since they go through nearly identical code paths.

Oct 12, 2011 at 6:05 PM

Source is UNC. Is there anything else I can do to gather information on why this is happening?

Oct 12, 2011 at 8:01 PM

You can use ProcMon.exe which is like Fiddler for file access. http://live.sysinternals.com/

Add a filter for 'Process Name is nuget.exe' then try installing.


Oct 12, 2011 at 9:27 PM

Couple other things to try:

  • Do you see the same in all machines, or just one specific one?
  • If all else fails, you can try debugging nuget
Oct 14, 2011 at 11:02 PM

ProcMon shows this failure:

NAME NOT FOUND: \\homer\rdrive\IT\Dev\Packages\Cclp.Core.1.71.6687.nupkg

It is looking for the .nupkg file in the root package directory; however, the .nupkg file is actually in a subdirectory corresponding to the ID of the package. I don't know for sure why it is in a subdirectory, but I thought that's where it was supposed to go; most likely I was following a walkthrough on someone's blog post when I put it there. I confirmed that if I move the .nupkg file from the subdirectory to the root directory, the Install command is able to locate it. So it seems that the List command, and the Visual Studio package manager, are able to find the package in the subdirectory, but the Install command is not. Is this a bug in Install or List? I would prefer to continue putting the packages in subdirectories for the sake of organization.

Thanks kiliman for the ProcMon suggestion.

Dec 12, 2011 at 2:30 PM


Has this been confirmed as a bug, or is it expected behaviour? I've just run into the same issue: We have a file-share local source set up, but NuGet Install can't find packages in sub-directories.


Dec 22, 2011 at 10:38 PM

I filed an issue on it, sorry I never posted it here. Apparently it is a bug, List is not supposed to look past the root of the package source.


[Actually it looks like you found it already]

Dec 24, 2011 at 1:02 AM

Yep, I found it a little while afterwards. Maybe I should have come back here and edited to say so.

Thanks for the reply