I have been a Java developer for over 10 years, during which I have used Maven or one of it’s successors (Gradle or Ant+Ivy) for build and dependency management. It was obvious to me early on that Maven’s dependency management was its killer feature. I began evangelizing Maven and converting teams to use it. The days of checking .jar files into version control were over, and I rejoiced!
Six months ago, I started coaching a number of .NET development teams on Agile Engineering best practices. This was an eye-opening experience for me and I learned a lot about .NET. While there were some bright spots, namely C#, I was surprised how .NET seemed to be lacking in certain areas that were fairly mature in the Java community. The most notable omision was the lack of a dependency management framework for .NET.
After my experiences with these teams, and discussing this problem with other .NET experts, I have come to realize that the standard practice is to check in .dlls to version control. I was appalled. When coaching teams on conduct unit testing, build automation, and continuous integration, I found the lack of a proper dependency management solution to be a huge problem. Adding .dll’s to version control works ok for third-party libraries, but when I want to consume a “working” version of another team’s code as they change it, this becomes a burden that Maven solved gracefully.
I then discovered NuGet, and hope returned. NuGet is a .NET open source project that’s sole purpose is dependency management in .NET. Yes, just what the agile engineering coach ordered. Right? Wrong. NuGet, while a promising project, is still young and lacks numerous dependency management features. NuGet was originally designed as a Visual Studio extension for allowing developers to search for, download and add libraries to their solution. Developers would then check in the .dlls to version control. What!? Isn’t this what we are trying to avoid?
In reading the forums (here, here, here, and here), it appears that users where complaining that NuGet wasn’t doing enough dependency management. In fact the project organizers were hesitant to add Maven-style dependency management. “We need NuGet to support continuous integration!”, the community cried. Well thankfully, NuGet is an open source project and the features for restoring dependencies has been added to the 1.6 release. With this release, you Nuget can be setup to restore packages that haven’t been checked in, as well as support for “beta” releases. For me, this change is still half cocked and fails to establish the benefits that Maven provided years ago.
NuGet is a promising young project and I hope that it will continue to grow and do well. The .NET community desperately needs it to grow up fast and support more features. In the spirit of open source development, I have done my part to support the project by submitting a bug report. I wish the Nuget team, as well as the rest of the .NET community the best of luck.
Stephen Ritchie
December 19, 2011
In you struggles to deal with NuGet …
have you seen this post: http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
or this one: http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html
what do you think of the up and coming TeamCity 7 integration with NuGet? http://confluence.jetbrains.net/display/TCD7/NuGet+Packages+Installer
Mike McGarr
December 19, 2011
First off Stephen, thanks for the comment and I am looking forward to reading your book (pre-ordered it).
Regarding the two blog posts you provided regarding NuGet’s restore feature, I have read them and they were a great starting point. Once I got it working I was optimistic about NuGet, although a little disappointed that it required the installation of NuGet Powertools to get it working. Also disappointed that it requires the versioning of the .nuget directory which contains the nuget.exe, for every solution. While this allows the project to look and operate as a standard msbuild project, it seems kind of hokie. This compared to Maven and Gradle, where this functionality is baked in from day one. If msbuild allowed declarative extensions or plugins (like Maven does), then you could extend your solution’s build process with NuGet, without checking in the executable. My final test for NuGet will be establishing full-blown build pipelines with component changes kicking off builds on dependent projects. That is the next step.
It is also slightly disappointing that the ‘Enable Restore’ feature is turned off by default. This should be default behavior in my opinion. This would help NuGet style dependency management adoption by the .NET community.
I am encouraged by the addition of the NuGet Pre-release feature in NuGet 1.6, which looks to be similar to Maven’s SNAPSHOT dependency. This, in conjunction with an enterprise hosted NuGet feed will help teams adopt NuGet faster. Having a NuGet repository built right into the best .NET continuous integration server, TeamCity, is awesome as well. I would upgrade my client right now if it was a stable release.
Don’t get me wrong. I criticize NuGet in the hopes of helping push it forward. It’s a great project and needs to be continually propelled forward!