Tuesday, 21 May 2013

Retrieving NuGet package programatically using NuGet.exe classes (not command line)

Following from Consuming NuGet programmatically outside VisualStudio (downloading the list of packages) , here is how I was able to consume NuGet.exe directly and create a strongly-typed NuGet Packages object

I started by opening up NuGet.exe in ILSpy and see what it’s Main method is doing:


It looks like there is a Program class that is used to load data and eventually execute a command.

So lets open up a C# REPL script and try this out.

We start with importing the NuGet.exe and creating a new instance of the Program class


Then (following the rewrite of the code in the NuGet’s Main method), create a Nuget.Common.Console object and add a Console Out viewer to the the top panel:


Now after executing the Initialize method (which is private so we need to use reflection to invoke it), we have a list of available commands


which are the same ones that are available via the command line:


If we open up the .details() view, we can see that the info we want is in the CommandAttribute.Description Property


Here is how to access the CommandAttribute property


Here is the description of the first value:


And here is simple foreach loop that collects the descriptions for all commands:


Here is how to create a command’s dictionary indexed by the command’s name:


With this dictionary we can access the command by name:


At this stage, executing the help command throws an error:


But the list command is ok.


we’re getting close now..... :)

Handling SSL Error

If you want to see the traffic that is happening when a list command is executed, and set-up a proxy like Fiddler, you will get this error:


which can be resolved using the Web.Https.ignoreServerSslErrors FluentSharp method


Now in fiddler we can see that there are a bunch of requests made, in this format:

GET /api/v2/Search()?$filter=IsLatestVersion&$orderby=Id&$skip=0&$top=30&searchTerm=''&targetFramework=''&includePrerelease=false
GET /api/v2/Search()?$filter=IsLatestVersion&$orderby=Id&$skip=30&$top=30&searchTerm=''&targetFramework=''&includePrerelease=false
GET /api/v2/Search()?$filter=IsLatestVersion&$orderby=Id&$skip=270&$top=30&searchTerm=''&targetFramework=''&includePrerelease=false
GET /api/v2/Search()?$filter=IsLatestVersion&$orderby=Id&$skip=600&$top=30&searchTerm=''&targetFramework=''&includePrerelease=false


After a bit of experimentation it looks like 30ish is the max that can be retrieved by that GET command.

Also there is a LOT of stuff in there (specially when all I wanted was the list of available package names)


Btw, where is the NuGet v2 API spec, I can’t see to find it and says:


Retrieving the packages data:

So looking at the the list command code, we can see that it’s GetPackages() method is the one used to control the download (the rest of this method displays the data in the console out):


The .GetPackages method is an IEnumerable which means that it will trigger the requests on demand


Now ideally, since we can create an instance of the ListCommand class


We should be able to just execute it’s GetPackages method (sepecially since when the normal ExecuteCommand method stores the GetPackages in a local variable (to the ExecuteCommand method)


But that doesn’t work because we get this error:


Which basically means that there is some object that needs to be set before the GetPackages call is made

And that is on the Command object Execute method (which is the one executed when we call listCommand.Execute)


with the ExecuteCommand being the abstract method (overriden by the actual command class (like the ListCommand))


Ok, so this is a bit of a pickle since clearly there are a bunch of objects that are set in the Command.Execute which need to be set before we can call the ListCommand.GetPackages method.

BUT, the Command.Execute will call the ListCommand.ExecuteCommand, which will trigger the (non desired behaviour of) downloading of all available packages.

The solution is to (re)implement this method in our script using reflection.

This would be easier if all the classes and properties used where public, but since they are not, we need to use a bit of reflection.

Here is the config part of the Command.Execute method (with this.ConfigFile== null  and minus the last line):


(in comments are the original lines of code, followed by the C# script that does the same thing using reflection and inside a lambda method)

And now it works :)


We can control how many articles are fetched by using the .take(…) command:


And if we look at the traffic that happens, when we request 29 items:


there will be one request made


.... if we ask for 50:


there will be 2 requests made


... and for 250:


there will be 9 requests:


And if we ask for all packages:


we will get 406 requests (and +/- 12180 items)


At this stage we have found a way programmatically access the NuGet Commands included with NuGet.exe, to for example get the entire list of NuGet Packages as nice strongly-typed objects (note that these objects all the info we could ever want from NuGet)

See also Offline copy of the entire gallery. What should I do with these 4.05 Gbs of amazing .Net Apps/APIs?