Dependency Management in .Net: install2

Inspired by Rob Reynoldsawesome post on extending NuGet’s command line, I decided to create my own extension for facilitating application-level, build-time retrieval of external dependencies along with all transitive dependencies. I struggled a bit with what to call the command since what it does is really what I believe the regular install command should be doing (i.e. installing transitive dependencies), so I decided to just call it install2. Here’s how to use it:

Step 1: Install the NuGet Extension package by running the following command:

$> NuGet.exe Install /ExcludeVersion /OutputDir %LocalAppData%\NuGet\Commands AddConsoleExtension

Step 2: Install the extension by running the following command:

$> NuGet.exe addExtension nuget.install2.extension

Step 3: Create a plain-text packages file (e.g. dependencies.config) listing out all the dependencies you need. For example:


Step 4: Execute Nuget with the install2 extension command:

$> NuGet.exe install2 dependencies.config

If all goes well, you should see the following output:

Attempting to resolve dependency 'Iesi.Collections ('.
Successfully installed 'Iesi.Collections'.
Successfully installed 'NHibernate'.
Successfully installed 'Moq 4.0.10827'.


About Derek Greer

Derek Greer is a consultant, aspiring software craftsman and agile enthusiast currently specializing in C# development on the .Net platform.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #946()

  • This looks excellent, we’ve been struggling with the best way to incorporate NuGet into our builds. Is there any support for (or planned support for) specifying an allowed version range? Or is the source available somewhere?

    • Anonymous

      This isn’t supported right now since the install command, which my extension relies upon, doesn’t appear to currently support ranges.  I’ll see what I can do though.

      This turned out to be pretty easy, so its there now in version

  • Todd Edwin King

    OpenWrap solves this problem pretty well now, and I hope better in the next version(s).  These build time objectives are what led me to OpenWrap after I determined that NuGet’s scope/objectives aren’t as powerful/useful as I was hoping.

    It’s good to see extensions like this though, as it looks like there is hunger for more advanced usages of NuGet.

    • Anonymous

      The advantage of this approach is that it provides solution-level dependency management independent of any particular build tool.  One of the things I don’t like about OpenWrap is the modification of project files to insert hooks to OpenWrap’s custom MSBuild tasks.  I’m also not sure I like the “magical” referencing of all assemblies.

      • Todd Edwin King

        Project file modification notwithstanding, we use MSBuild and find that convenient.  I’m sure OpenWrap’s goal is to have no specific build tool dependency.

        As to “magical” referencing of assemblies, that is what enables the system we have built to manage cross-team dependencies.  Dependencies are not kept with source code (except where necessary) and are pulled during build process.

        This goes well beyond NuGet and OpenWrap purview, but our needs go well beyond just making it easy to get and maintain open source dependencies.


  • Chris Pont

    Good work, and a nice simple solution.

    Similar to OpenWrap, but NuGet Powertools does this too, as described here…
    The advantage is that if you build using CI such as Jenkins, the dependencies will be resolved every time, and NuGet will keep the configs up to date if you decide to upgrade any packages.

    • Anonymous

      The intent of this extension is to use it as part of your CI build process, so I don’t see OpenWrap or NuGet Powertools presenting any advantages over this from a CI perspective.  This solution does have its own advantages, however, in that it isn’t tied to any particular build tool (OpenWrap and NuGet Powertools both rely upon custom MSBuild tasks and modification of your project files to work) and it allows you to maintain a simple solution-wide manifest to denote your project’s dependencies.