Unless you’ve been living in a cave, you’ve likely heard about ASP.NET 5--and some of the big changes it will be bringing to Web development for .NET developers. Personally, I just haven’t been able to keep up with all of the low-level details about what is being changed or improved, but I have been able to stay abreast of some of the bigger changes and the overarching strategy improvements that ASP.NET 5 represents. Things are starting to look very exciting.
.NET Core
Of course, one of the best places to get information about what’s new or next in ASP.NET is to simply follow Scott Guthrie’s blog. Yesterday he dropped a great blog post, Introducing ASP.NET 5. It’s well worth a look--if you haven’t already read it--providing a high-level overview of some of the biggest changes and improvements.
Right out of the gate, though, the thing I’m most interested in and excited about is the .NET Core--a new, optional runtime that promises some amazing things, including streamlined execution, optimized Azure support and the ability to allow cross-platform execution at run time. And, while all of those benefits are substantial, what I am really looking forward to about .NET Core is that it will be totally modular.
From Scott’s blog:
You can deploy the .NET Core runtime with your app which means your app will run with this deployed version of the runtime rather than the version of the runtime that is installed on the host operating system. Your version of the runtime runs side-by-side with versions for other apps. You can update that runtime, if needed, without affecting other apps, or you can continue running on the same version even though other apps on the system have been updated. This makes app deployment and framework updates much easier and less impactful to other apps running on a system.
For me, the notion of a fully contained runtime is powerful and amazing. Not only does it conjure up notions of svelte apps perfectly seasoned with just the right NuGet packages (all in one nice, tidy bundle), but it also potentially signals the end to a rather ugly problem I’ve been encountering with ASP.NET MVC applications during the past few years.
The issue or problem? Versioning.
I’ve written about this problem in the past. And it’s sadly something I deal with semi-regularly. In short, the problem is that I’ll build an ASP.NET MVC site, deploy it and then I’ll effectively forget about it for a few months or even a year or so. Then, later, I’ll need to make either trivial or minor changes and will attempt to go in and build the app--only to find that since it was deployed, I’ve installed newer versions of Visual Studio, MVC and even the .NET Framework. All of this combines to mean that the website I need to make changes to simply won’t compile without a decent amount of work sorting out an effective version of .dll hell.
With this newer, .NET Core runtime as an option, I can envision a future where having self-contained apps that don’t break over time may become an eventual reality.
Granted, the .NET Core won’t be as full of a stack as the "full" .NET Framework, so it may take a bit of time before this possibility can be fully realized. But, by the same token, another huge benefit of the .NET Core is that it’s a modular--something that Microsoft and the ASP.NET Team can continue to build upon, improve and advance as time progresses. Moreover, because it’s a bold departure from the full .NET Framework, this also means that .NET Core releases won’t be tied down to monolithic releases in lock-step with Visual Studio every few years. Instead, what we can hope to see will be more regular releases that are much more agile in scope and implementation than anything we’ve seen previously.
But Wait, There’s More!
I was also going to spout off on some reasons why I’m also excited about the fact that ASP.NET 5 will provide a unified programming model (as outlined in Scott Guthrie’s post) because I think it’s a huge win.
Personally, once I understood why MVC and Web API weren’t fully compatible (because Web API was "rewritten from the ground up" so that it could be hosted anywhere), I didn’t find much of the "duplication and inconsistencies" that Scott mentions to be too big of a problem. Or, more importantly, I would have rather dealt with those hassles any day of the week than even look sideways at that obscene pile of rubbish that is WCF when it comes to trying to create solutions for simple data interchange.
As such, the unification of ASP.NET Web Pages, MVC and Web API into a single, unified programming model is a big win when it comes to simplifying apps. Only, in my mind, that’s just the tip of the iceberg. Because what this really means is that ASP.NET has finally been written to no longer take a dependency upon System.Web.dll--or upon the older, more monolithic approach to tackling Web development that we’ve been dealing with for years.
As such, I honestly see ASP.NET 5 as representing a whole new approach to Web development going forward. Much of that will be missed or seemingly hidden from view, as the ASP.NET team has put substantial effort into making sure that developers don’t feel too much like their cheese has been moved. But, make no mistake: The horse we’ve been riding for the past few years has been switched out from under us and replaced with an optimized and highly modular dune buggy that we’ll be able to take to spectacular new places.
In fact, you’ll catch glimpses of that in Scott’s post when he talks about Fast HTTP performance (as well as Dependency Injection), as so many of the "new"things we’ll see available in ASP.NET 5.0 will be due wholly or in large part to the fact that we really are dealing with what amounts to a major rewrite of ASP.NET under the covers.
ASP.NET 5: The Biggest Thing since ASP.NET 1.0
I still vividly remember when ASP.NET 1.0 was released. It represented a huge paradigm shift.
Fortunately, ASP.NET 5.0 doesn’t represent much of a paradigm shift at all. But, under the covers, some amazing things are going on, and I’m convinced that ASP.NET 5.0 is simply the biggest set of changes we’ve seen since the introduction of the .NET Framework.
I do expect to run into some problems and issues with this release, especially when it comes to lower-level "plumbing" and versioning concerns. After all, a significant amount of change has happened to ASP.NET, so it would be naïve to assume that there won’t be some friction.
Still, once my "teething issues" have been solved, I’m convinced that this vibrant new take on ASP.NET will leave me with solutions and applications that remain dramatically easier to manage and maintain going forward. And that, no matter how you slice it, is a gigantic win.
