Sunday, February 28, 2016
Nuget - the new dll hell
Back in the early 2000's, when I first started programming on the Microsoft stack, COM objects were all the rage. This of course had a side effect of something known as dll hell, where an application could change a version of a dll your application depended on, thus breaking your application in the process or causing subtle bugs that where hard to debug. .Net was supposed to change all of that with side-by- assemblies and versioning and for the most part that has worked well. Enter Nuget, nuget was intended to centralize project dependencies and libraries. So for example if you needed to parse JSON files in your application, you could locate a package that contained a JSON parsing library and add it. The reference to the nuget package could be easily shared across teams and build systems. The problem is that many of these libraries come with a proliferation of their own dependencies and in some cases those dependencies are older versions. A case in point, on a an application that I'm currently working on, I have a dependency on JSON.Net, I upgraded to the latest version 8.0.2 only to find out that another package that was referenced had a dependency on 6.0.0 so upgrading broke functionality in the other library (the other library BTW is a Microsoft Library). The eventual work around was a binding redirect in the app config. But this still points to a bigger problem that of library maintenance and vetting libraries that are available on nuget. No one to my knowledge vets these packages and updating certainly isn't enforced. So now we have come full circle in the dll hell story, we are essentially right back were we started in the COM days.