The .NET Framework and the Gradual Return of DLL Hell

Related: "Microsoft's .NET Framework 4.5 Versioning Faces Problems Ahead"

One of the earliest and biggest promises of the .NET Framework when it was originally released was that it would free us from DLL Hell. Stated differently, it would free us from the pain and troubles associated with multiple applications being dependent on a single set of libraries, along with saving us from the headaches caused when any part of that shared library was updated or when any of those apps tried to update or overwrite parts of the same, shared codebase amongst all apps. Unfortunately, I'd argue that recent versions of the .NET Framework have increasingly begun to leak several different, painful versioning problems and issues.

Related: "New Features in Visual Studio 2013 and .NET Framework 4.5.1"

Problems with the .NET Framework

I've got two MVC 3.0 applications for two of my sites (my primary SQL Server Consulting site and SQLServerVideos.com). As much, as I thoroughly enjoyed building both of these sites on MVC 3.0, I'm a bit loathe and even wary of upgrading them to MVC 5.0 -- simply because of some problems I've had in keeping these applications functional when merely installing new versions of the .NET Framework and Visual Studio on my box after these apps were created.

For example, I went ahead and installed MVC 4.0 and Visual Studio 2012 onto my workstation when they were released to market as a successor to Visual Studio 2010. Little did I know that in doing so, I actually busted many of my MVC 3.0 sites simply by putting new assemblies and references into the GAC. Instead, what happened was a few weeks later I needed to make some simple cosmetic changes to the copy along with some minor bug fixes to one of my sites, only to find that it would no longer compile as a MVC 3.0 site because of the number of assembly reference errors being thrown by the compiler when I went to F5 the site for a quick test-drive after making some of those minor changes.

Unfortunately, this problem is now something I've more or less come to expect when deploying new versions of ASP.NET and Visual Studio onto my developer workstation. To be fair, it doesn't happen with every site. However, the fact that the mere installation of a new version of Visual Studio and its attendant version of the .NET Framework and ASP.NET frameworks can break even one site is still a problem, which hints at what David Sobeski elegantly defines as a trust problem that Microsoft really needs to address.

Placing Blame on Visual Studio, Microsoft, or the .NET Framework?

On one hand, it's pretty easy to blame Visual Studio, Microsoft, or the .NET Framework when my sites don't work. To be perfectly fair, both of the sites I'm complaining about include some degree of customization, so it's probably fair to level some of the blame on me. On the other hand, although that customization does include some hacks and tweaks to get around the need for Role and Membership providers as well as a couple of custom Action Filter Attributes, none of those seem to really cause me any grief. Instead, where I run into the largest amount of pain outside of properly configuring Dependency Injection Frameworks seems to stem from custom strings usage via the MvcHtmlString interface, which is something that hardly seems like it should cause problems.

Granted, these typically minor breaks aren't the end of the world, as they usually take about 20 to 40 minutes of Googling until I can find people complaining about similar issues on StackOverflow. But installing new versions of Visual Studio and the .NET Framework shouldn't break previously functional applications. Something about that scenario just seems wrong.

In hindsight, a couple of these problems have been corrected by going in and adding more verbose versioning details to various parts of my web.config, so it might be argued that the problem here might actually just be a problem with .config files or compiler directives. Only, I see two major problems with that. First, the .config files I'm using aren't anything special -- they're config files shipped with the versions of MVC I've built my apps with; if I were in making big changes, then it would seem safe to assume that was the problem. Second, fiddling with config files and versioning attributes doesn't fix all of these problems – especially when code jumps from one assembly to the next between versions.

As such, I honestly feel that the problem here is that the .NET Framework itself has become both too unwieldy and monolithic and has also become entirely too tied to being shipped with Visual Studio. Accordingly, I feel that while I'm sure I could probably do things better on my end to mitigate this problem going forward, the real fix for this ongoing and increasingly more prevalent problem is going to have to somehow involve changes to the .NET Framework itself.

A Brilliant, Long-Term Solution

The problem with such an assertion, however, is that I'm not smart enough to have figured out a good or viable fix for this increasing problem of DLL Hell that I've been bumping into with the last few releases of the .NET Framework. Happily, though, there are much smarter people than me out there who've come up with some great ideas. In fact, I highly recommend that you read Mark Rendle's thoughts about some of the exact same problems and issues that I've complained about here in his blog post entitled, "How I Would Like Microsoft to Distribute .NET v.Next." His thoughts are much less focused on complaining about the problem itself and are much more focused on what I think is a fantastic solution: a more streamlined and simplified set of base class libraries. Better yet, he does a fantastic job of arguing for a much more streamlined and much more composable framework that, I think, would be much more portable and much less susceptible to DLL Hell than what we're currently seeing.