NuGet install-package doesn't work. How can I get more verbose information to help debug why this is failing?

Question

A collegue is trying to install a nuget package into a simple default c# web application. It fails almost instantly.

Is there an argument I can provide to Install-Package <some nuget package> in the Visual Studio Package Manager Console to get some verbose information to help debug why the installation fails?

Error Message:

An error occurred while retrieving package metadata for '' from source 'MyGet'.

Info: Visual Studio: V2015 NuGet extension: 3.4.4.1321 Nuget package source: MyGet

Sample NuGet.config file found in the root directory of the solution:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="MyGet" value="https://www.myget.org/F/<our package>/api/v2" /> 
  </packageSources>
</configuration>

For myself, I can install the package fine. In fact, we have 5 packages in this MyGet public repo and I just installed 2 of the packages, just then .. when I test this out (again) before I created this SO question.

Anyone have a suggestion, please?

UPDATE

As stated above, this is using the PACKAGE MANAGER CONSOLE, not the CLI.

Using the -verbosity detailed in the PMC this is what happens..

PM> install-package xunit -verbosity detailed
Install-Package : A parameter cannot be found that matches parameter name 'verbosity'.
At line:1 char:23
+ install-package xunit -verbosity detailed
+                       ~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Install-Package], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand

Solution 1

Looks like you are running into http://blog.myget.org/post/2016/02/21/Two-of-my-packages-are-treated-as-one-Help!.aspx. There is a 0.7.0-dev and a 0.7-dev version of the package on the feed, which NuGet treats as the same version.

The solution is to remove one of these two packages.

Solution 2

You could try adding the -Verbose parameter to your PowerShell command.

 install-package xunit -verbose

You can also try looking at the $error object to see if that has more information, such as an exception callstack.

$error.Exception.StackTrace

The above may or may not give you more information.

Solution 3

You can use the -Verbose switch in the PowerShell-enabled Package Manager Console to get more details.

To rule out client-connectivity issues to MyGet, can you try diagnosing client connectivity to the feed?

https://www.myget.org/F/<feedIdentifier>/api/v2

Try using Fiddler to retrieve a specific package from the feed on that user's machine using URL format:

https://www.myget.org/F/<feedIdentifier>/api/v2/package/<packageId>/<packageVersion>

If it is a private feed, you'll need to authenticate your request, e.g. using the pre-authenticated v2 endpoint:

https://www.myget.org/F/<feedId>/auth/<apiKey>/api/v2/package/<packageId>/<packageVersion>

Clearing the NuGet client's HTTP cache may also prove useful if something is corrupt in the cache. You can clear it using the NuGet commandline command:

nuget.exe locals http-cache -clear

If the package is already in local cache, then the NuGet client will resolve it from local cache instead. It may be that the package in local cache is corrupt, in which case you can use the following NuGet commandline command:

nuget.exe locals all -clear

Finally, it may also be worth looking at the nuget.config hierarchy. The most-local nuget.config will inherit config settings from higher up the chain (e.g. machine-wide settings), one of which is the <disabledPackageSources> element. To ensure this one is not acting up here, add the following to your most-local nuget.config and retry:

<disabledPackageSources>
  <clear />
</disabledPackageSources>

If none of the above helps you in resolving the issue, feel free to use the nuget commandline (nuget.exe) with -verbosity detailed as it may provide more details, such as the actual HTTP requests being made.

Also, make sure you use the latest versions of the NuGet client tools (available here)

Comments

[JustinN]

Just thought I would add, I am the colleague in facing the problem. The issue still persists right now with the NuGet GUI, however I have just tried it with the console, and it works perfectly. I don't know if the UI is sending extra information over which is causing the MyGet service to be upset, I could try run Fiddler to find out, but right now it seems using the console (as usual) works correctly as expected.