Provides a set of extensions to NuGet. Many of these are aimed at large corporate Development Operations teams, and the management of large numbers of feeds, packages, relationships, and a different level of complexity than might be normally found in the consumption of NuGet packages for open source projects.

#Commands

Targetted at the package restore use case, but does only what it says (it **get*s the packages, not install or update). Simplified restore of full solution or directory structure NuGet package requirements. Designed to be very fast for large numbers of package dependencies. Provides caching, minimum package set identification including version ranges, resolution and download of only the smallest distinct set of packages per solution and many more advantages.

Find a specific assembly within packages on a specific feed.

Allows you to query details about a specific package ID from the commandline. Provides information such as the file paths, dependencies, authors etc.

Provides the ability to graph the package dependency for an entire feed. Also lets you know if there are any cyclic dependencies on your feed. Primarily aimed at large internal feed management.

For an example of the output, the graph below was produced by pointing it at http://nuget.org. Turns out, their graph is currently acyclic (this is a GOOD thing!). There are quite a lot of disconnected graphs, and some quite interesting clusters of usage. Worth a browse.

To have a play with the data yourself, you can load the DGML graph directly into Visual Studio 2010 or greater from here.

The teamcity command produces a dependency graph of all NuGet publish and subscribe relationships on a TeamCity build server. With the ability to pack, publish and trigger directly from NuGet packages, as well as its ability to function as a NuGet OData feed, TeamCity provides the perfect platform to produce and consume NuGet packages on. This command makes it very easy to graphically represent these publish/subscribe realationships.

Using the option -packageasvertex, you will get a graph that represents each build configuration as a solid node, and each package as a label with edges representing dependencies. See below for an example. This graph was built with packages being published via both NuGet Package build steps, and directly from the artifacts.

To have a play with the data yourself, you can load the DGML graph directly into Visual Studio 2010 or greater from here.

The "nugetify" command allows a simple conversion to using simple file references to using NuGet package references. What it does:

1. Provided a feed and a solution, try and find a package on the feed that contains a file matching each file reference for each project.
2. Write packages.config files for each project with resolved package to reference mappings.
3. Update all hintpaths within projects.
4. Create packages directory and repositories.config file.
5. Optionally create a nuspec file for each project output, including adding dependencies and output files.

It works best if the feed you want to satisfy the file references with is a local directory. To get a useful local directory, look at the "clone" command here as well. Clone the feed locally, prune it if required, then run nugetify. Using an SSD you can get pretty snappy results.

What it does not do (currently):

1. Only satisfies the build dependency closure. It does not do the same thing as a "nuget install" as you will not get the full transitive runtime closure. It will purely provide a mapping between your file references and packages that will provide them. THIS IS BY DESIGN! If you want full transitive closure, post running "nuget nugetify" run a "nuget update".
2. It does not support versioned package directories. Again, by design. It may change (its trivial) but it is such an annoying default for such an edgecase usage...frankly versioned package directories piss me off.
3. The whole thing should be considered "pragmatic" code. It seems to work on my machine. Its not pretty. It could be faster. It will get better.

Clone a feed from one location to another. Also provides the ability to refresh a feed (update any packages that already exist from another feed).

Copy a package from one feed to another (INCOMPLETE)