How Do You Manage Dependencies in Your .NET Project?

Every .NET developer has been there, sitting down, opening up VisualStudio, creating a new solution for some project (ha! no pun intended), and then adding the miriad of references to external libraries that you need in order to keep yourself sane through the coding experience. Each library you download and add to your projects becomes a dependency, almost a liability.

Enter Nuget. It’s pronounced “new get”. Quite simply NuGet is an open source (free) package management tool for .NET. If you’re familiar with Maven in Java then you’ll have a good understanding of some of the features NuGet provides. NuGet arrived on the scene in late 2005 as a project called NuPack by Pill Haack. Phil started the project with the Outercurve Foundation. I’m not entirely clear on how, but Microsoft created their own fork of the project and placed it into codeplex as NuGet. From there the project really took off. The Microsoft team even includes their own version as an extension in VisualStudio 2012 by default. In actuality the only real “extension” allowed in VisualStudio Express is this Microsoft version of the NuGet package manager.

For more behind the creation of NuGet and Phil Haack’s ideas on the project I suggest reading his assessment of the project. He clearly has some ideas and expectation on the growth and development of the project that are far outside the scope of this post.

What Can This Tool Do For Me?

NuGet allows you, the developer, to manage the libraries in your project. By connecting your solution to the Official NuGet Package Feed you’ll be able to import projects that you use every day such as Log4Net, JQuery, and Spring.NET. This gives you a huge advantage as a developer. No longer do you have to go out and download a specific version of a library to import. No longer do you have to maintain where you place these libraries in your project structure. The worry about having other developers getting the correct version or placing the library into the solution in the right spot is mitigated by NuGet.

In NuGet you specify what packages are loaded into each project, which version is used, and the allowed versions for upgrades. In the end a developer completely controls how a library is integrated into a solution. When package restoration is added to a solution a simple config file, executable, and build targets are included into the solution and the appropriate projects. Whenever a build is triggered the script checks for the packages and downloads them as necessary.

How Else Can I Use NuGet?

Consuming packages is only half of the power of NuGet. The publishing of packages to the community gallery is the other half of the equation. The more libraries that are published the better the coverage for libraries which are used by the multitude of .NET developers. This helps developers cut down on the dreaded process of re-inventing the wheel.

Now if you’re like me one of the first questions that will pop into your head is whether or not you can use this in your corporate environment. Most companies allow their developers to use third-party open source projects in their solutions. The sticky situations are created when developers actively change code in the open source project. However, what happens to libraries that are internally developed? Every company I’ve worked for absolutely does not want their intellectual property and business logic just posted out in the open.

What is a Team of Developers in an Enterprise Situation To Do?

You just setup your own internal gallery or feed! The whole NuGet project is open source, from the VisualStudio plugin to the NuGet executable. The NuGet project even has published a package that you can include into a solution which creates a web application that will host a single feed of packages. If you’re sharing packages between teams and want to manage users you can even setup your own internal NuGet Gallery just like http://www.nuget.org.

Recently I did this for my company. I initially started with a feed web application created by a NuGet package that is hosted in the official feed. This was good for internal use by our team members. I have since setup the gallery server which allows for any developer to apply for an API key to publish their own package. Now, I’ve done several tweaks. I added our company’s branding to placate management. I then changed the code so that when a user registers an email is sent to an administrator for approval instead of the user which initiated the registration.

By keeping and using libraries in NuGet your build process should also get a little less complicated. A special NuGet build target is added to projects requiring packages from a NuGet feed.  When the build runs, whether on a TFS server or through a MSBuild call, the targets file will call the NuGet.exe to make sure all packages are downloaded.

In all NuGet is a powerful tool to add to your developer tool belt. For small projects it keeps the hassle of maintaining and upgrading libraries to a minimum. If implemented in an enterprise situation it can help teams share libraries and keep from re-inventing the wheel.

Head over to the Gallery or CodePlex site to get started with NuGet in your next project!