ASP.NET vNext: Big Things Ahead for Developers

At TechEd 2014, Microsoft announced the biggest changes ever to ASP.NET. Obviously, the fact that ASP.NET vNext is designed to run on Windows, Macs, and Linux is a huge deal, and it has garnered a huge amount of attention by developers and the press. The fact that ASP.NET vNext will also be effectively open-sourced and is already making its way up to Git has also received a lot of attention. What I personally found most significant was Project K—or the fact that ASP.NET vNext will be a leaner, meaner, cleaner, and more-streamlined version of ASP.NET than we've ever seen before.

Good Riddance GAC

There are several different reasons that I've hated the Global Assembly Cache (GAC) over the years. The majority of those reasons, of course, would stem from problems of DLL Hell that it has forced upon me, which I've detailed in my article, "The .NET Framework and the Gradual Return of DLL Hell." The other thing that has stuck in my craw about the GAC has been its management. Trying to accomplish any sort of GAC management has been obtusely problematic since the introduction of .NET Framework 2.0.

Part of that seems to stem from a power-struggle between various departments and their lawyers at Microsoft about who owns the GAC, how it's supposed to be managed, and whether it makes sense to ship tools to manage the GAC directly with Windows or to restrict those tools to just developers only (by license or forcing developers to install Windows SDKs). I've written about the problem with GAC in the past, and the problem simply hasn't gotten better over time until now; I can finally see the GAC gasping its last breaths.

Suffice it to say, I won't be mourning when the GAC is no longer part of my life. In fact, the best website I've probably visited all month is a fantastic and hilarious site created by fellow ASPInsider, Mark Rendle, called RIP GAC. Go take a few minutes to check the site out and make sure to read the GAC's Eulogy, as well as information about its successors and survivors.

Putting Versioning Pain Where it Belongs: On Developers

Of course, just because the GAC is dying doesn't mean that ASP.NET development will magically become all butterflies and unicorns. In some ways, I actually expect that ASP.NET development will occasionally become even harder—some of the NuGet packages we whip about in composable fashion might come back to bite us due to versioning conflicts.

The win for developers, though, is that these problems will manifest early on, when the reasons for using said components are still fresh in our minds and we're more up to speed on versioning concerns and details regarding all of the components we're using, as opposed to problems occurring 6, 8, or 20 months later, when we can barely remember some of the apps that end up getting busted.

In short, the benefit of removing the GAC from the equation is that the pain of versioning now occurs when developers are trying to verify the "Works on my Computer" aspect of their applications and solutions, instead of problems occurring at deployment time or, worse, months later, when Operations and IT folks are involved, and troubleshooting applications becomes exponentially more expensive. In my mind, that makes ASP.NET vNext much more valuable and palatable to IT organizations—it will be significantly cheaper to own and manage.

The Future is Full of Rainbows and Unicorns

I'm fully hoping and expecting that applications will be more portable and more stable by virtue of these applications being more self-contained (i.e., think more along the lines of XCOPY deployment, along with virtually all code and dependencies except for a very streamlined and optimized .NET Framework). But I'm also hoping that Project K and a newer, more composable, version of the .NET Framework for ASP.NET will engender other big benefits as well. For example, it's logical to assume that a more nimble and streamlined version of the .NET Framework will translate into quicker iteration and faster release cycles by the ASP.NET Team, as they won't have to wait for other groups or departments to work their own changes into the next version of the .NET Framework before the original features can see the light of day.

I'm also hoping that we'll eventually see a major change in how Visual Studio is tackled, as it should, in theory, become less attached to gigantic releases of the .NET Framework, and more suited for smaller, more agile releases. In fact, I'd argue we're already seeing this change, with the Updates'—we're already on Visual Studio 2013 Update 2. I hope this means that Microsoft will eventually be able to abandon their current practice of releasing SQL Server Management Studio as a second-class citizen that's typically either one or two versions behind the current implementation of Visual Studio. Maybe that's too much to hope for, but, then again, maybe it's not—I fully expect that kicking the GAC to the curb will eventually prove to be a wise move in the future.