I have some .NET projects that are starting to get large enough to merit looking into Dependency Management solutions, so we don't have to copy binaries from one project to another. Here's what I've found so far:

  • NPanday is based on a port of Maven. I can't tell how recently it was worked on, but the last release was in May 2011.
  • NuGet seems to be under active development, and it appears to have support directly from Microsoft. Some people complained that it "only addresses dependency resolution," but I don't know what else it should address, or whether it has added more features since that point. It does appear to have recently added the ability to import binaries as part of the build process so we don't have to commit them to our repositories.
  • Refix appears to still be in Beta, after having received no attention since Sept 2011.

Would somebody with recent experience using any of these dependency management tools (or any others that work well) share your experience? Is NuGet mature enough to use it for dependency management? If not, what does it lack?

  • 1
    You missed openwrap.
    – Oded
    May 16, 2012 at 16:17
  • I am developing one, it's still in alpha but used successfully in our company (over 50 devs). There are no docs yet, but it's opensource. NuGet didn't work for as, as well ass Refix and NPanday (which is an ugly Maven add-in).
    – Ivan G.
    Jun 5, 2012 at 20:58
  • @aloneguid: Can you share the reasons that NuGet didn't work for you? Jun 5, 2012 at 21:51
  • NuGet? It just looks dirty, sometimes runs PS scripts from packages, has PS dependency implicitly (you can argue, but it does). Too heavy in a VS. Doesnt (or didn't) detect version conflicts.
    – Ivan G.
    Jun 6, 2012 at 9:08
  • @aloneguid: Assume that I don't know anything about this topic. What do you mean by PS/VS? Jun 6, 2012 at 17:58

3 Answers 3


NuGet would likely be my answer. After working the precursor (Nu) which was just sitting on top of RubyGems, I can say that having resources towards something helps. Now once job I ended up with a patched version of the executable because we had a local repository besides remote ones. I'm not sure if they fixed that problem yet or not, but since they are accepting patches, it should be easy to correct. On all the open source projects in the .NET arena I work on we now do all of through NuGet. It's much easier, though publishing up the chain does take a little while longer.

OpenWrap is an option, but everything needs built. Which is kinda a pain in the butt. If you can't get the project building right it takes a while to deal with. Openwrap has been trying to solve this for a long time and it's still really awkward. Binary only distribution is a lot easier (sometimes)...

The other two I'm not familiar with. So I can't comment on them a ton.

  • NuGet is like a beginner's transition into package management. It probably only helps downloading packages more easily, but I'm not sure it does more than that. Compare it with Maven to understand what a dependency management system should do.
    – Ivan G.
    Jun 6, 2012 at 9:43
  • 1
    @aloneguid: So since I'm a beginner in package management, would NuGet be a logical first step for me to take until I determine that I have additional needs that aren't being met? Jun 6, 2012 at 18:00
  • @aloneguid Please check out the NuGet Package Restore feature that was introduced in NuGet 2.7. It looks like it may bring NuGet a little closer to the dependency management capabilities of Maven. Mar 14, 2014 at 16:37

I have just downloaded a latest version of NuGet to see what changed since the last time. Please correct me if I'm wrong (I'm really considering migrating my stuff to nuget):

NuGet packages still don't specify a "platform" as a package dependency. I have just installed "Ninject" and it referenced .NET 4.0 version in a subfolder "packages". I suppose it was a best guess as my project is in 4.0, but that is quite dangerous to suppose. I don't understand which platform will be selected by packages' dependency either.

"Package Restore" feature transforms my solution adding a custom pre-build step. I don't like something modifying my solution files, but that't not a problem. I don't understand how often it checks for the new versions (I'd like to set a frequency for private repositories to be quite often).

I may be totally wrong here, however it looks like nuget doesn't automatically upgrade project's dependency when a package version gets upgraded. Package Restore will create a new subfolder for a new package version, however I have to manually choose that folder from Visual Studio deleting the reference beforehand.

Some packages (like jQuery) will run an embedded PowerShell script on startup. I really don't like any custom execution and PS dependency which is not always there on windows and totally missing in Mono non-windows builds. By the way, as I mentioned MSBuild previously, even this dependency may be not realistic to satisfy for some C++ builds (otherwise I will miss Package Restore feature?).

The last one may be not that important, however it takes some reasonable amount of time to Restore Dependencies when I have quite a lot of them.


NuGet is still the best option at this point.

The main issue with NuGet as a dependency manager is that it was envisioned to be a "development time" dependency manager, not a "build time" dependency manager.

A developer would restore a NuGet package thru Visual Studio...and this could run a PowerShell script during the restore that modifies files in the project.

This is unlike other dependency management systems that I have seen, as adding a dependency and resolving it can alter the system referencing the dependency.

There is no built-in mechanism to ensure or check idempotency in the PowerShell script, so running it more than once on the same set of files may not be deterministic.

It seems many use NuGet to pull packages thru Visual Studio during development time, but I'm not aware of a solid recommendation for how that is supposed to work on a build server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.