Over the past few years, those of us in the .NET development space have been forced to jump on the NuGet bandwagon as it relates to adding certain dependencies to our own projects. No matter what our individual thoughts are with regards to NuGet we must learn to live with the tool and use it to the best of our abilities. Most of the time the packages that we use will be well-formed and managed in a responsive manner. However, as I recently learned, that isn't always the case. When things start to go awry it can make your standard diagnostic processes less than successful. Given these experiences, I wanted to share two recent experiences with NuGet, not in an effort to shame any of the involved parties but to help illustrate the importance of looking at solutions & packages in a different light than your standard development processes.
Version Numbers Are Not Always What They Appear
Recently I was working with an ASP.NET MVC project that was using Ninject for dependency injection. I modeled the configuration of Ninject in this solution like a similar project that was created a few months earlier. The new project was not properly creating/disposing of items defined with InRequestScope definitions. A fairly simple thing on the surface to diagnose. More than likely we had an issue with an incorrect version of a component, somehow either working with a newer or older version on the new project that had a bug.
Over the course of a few days, I reviewed the two applications, debugged the code, and tried to spot the differences. I did all of the things we normally do: Looked at the version numbers in the "References" for the projects to identify is the referenced assemblies were the same. The versions matched, I dug deeper and looked at the files themselves, the file sizes were identical and I investigated the file properties. In the end, nothing was out of place. Being less familiar with Ninject, I had another member of my team review, and they too were stumped.
Then it hit us....maybe we should check the versions in the Packages.config file. To our surprise, there was a difference in the version number of the package, but the version number of all included DLL's was not incremented. A simple difference, but very hard to identify when the assemblies used were similar in size. As developers, we should be sure to add version verification of not only Assemblies and Packages to our debugging lists. As individuals managing NuGet packages we should also be sure to increment items in a manner that helps those using our projects.
NuGet or Not For References
Another recent NuGet debate amongst my team, as well as a few others. Should I really use NuGet to add ____ to our project? This is one of the items that strike a lot of debate, but for sure was something worth discussing as we look at better methods to manage NuGet packages. My personal opinion here is fairly simple. If it is a .NET package, without a doubt it should be managed via NuGet. However, I've found that with other packages, such as jQuery, jQuery-UI, Angular, and the like that it might not always made sense to include using NuGet. Why? Well, I am fairly particular with my projects and I want to ensure that we follow a consistent structure within our application, not only for placement of items, but also in making sure that we only include items that we need.
Looking at many of the larger JS Libraries and other solutions I find that they include way more items than needed, and where they place the files in the solution is not as concise. Yes, by not using NuGet more work is needed to upgrade, but it also makes it more concise when integrating a new version. The end goal for me is to make sure that my solutions are easy to manage and that they will remain that way in the future.
Conclusion
I hope that these tips have been helpful. Don't get me wrong, NuGet makes our lives much easier 99.9% of the time, but it does at times require a quick step back to evaluate what is the best for our solutions.