Command line extensions for NuGet.
C#
Permalink
Failed to load latest commit information.
.nuget Remove deprecated MSBuild package restore Mar 15, 2015
NuGet.Extensions.Tests
NuGet.Extensions
images Update images Jul 2, 2012
packages Remove old package contents Mar 15, 2015
tools/ILMerge Initial commit May 24, 2012
.gitignore Git ignore VS2015 cache Mar 14, 2015
License.txt
Local.testsettings
NuGet.Extensions.sln Compiling….probably NOT functional. May 20, 2013
NuGet.Extensions.vsmdi
README.markdown

README.markdown

NuGet.Extensions

Build status

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

GET

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.

FINDASSEMBLY

Find a specific assembly within packages on a specific feed.

DETAILS

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

GRAPH

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.

NuGet TeamCity Package Dependency Graph

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

TEAMCITY

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.

NuGet TeamCity Package Dependency Graph

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

NUGETIFY

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

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

Copy a package from one feed to another (INCOMPLETE)