State of ASP.NET part 1: Leaving the parents
ASP.NET is working hard to loosen its connections to both Visual Studio and .NET Framework releases in general. What does this mean to you?
This post kicks off a three-part series on the state of ASP.NET. My goal is to provide an overview of what’s happening in the Microsoft web world. I want to start by giving the readers a clear picture of the current release models and cycles Microsoft uses. Later on, I’ll dive more into the specific features.
Update 2013-08-23: The version diagram below shows 8/2013 as release date for various products. The diagram was drawn in June, when the software was expected to be published to MSDN and volume licensees prior to general availability. At this juncture, it seems likely that the release date will be in September or October, October 18th at the latest.
Treat ASP.NET like any library
Traditionally, ASP.NET shipped with the .NET Framework, which then later got on to ship with the operating systems. This meant that changes in quite minor parts – such as adding a new feature into a Grid control – would require a full Windows release cycle to come around.
This is now changing rapidly. More and more of ASP.NET comes in NuGet packages, and the post-2012 rapid update cadence of Visual Studio enables the tooling to follow. And finally, there is the open source aspect: for many products, you can actually access, modify and even contribute to the source that will eventually become a Microsoft-supported product.
All this leads into a new guideline: Treat ASP.NET as a library. Take updates separately from your .NET Framework updates. Be eager and agile.
Once you’re past the Visual Studio 2012 hump, you will find your ASP.NET quite pleasant and quickly evolving that way – even more so if you’re able to go VS 2013. Once there, I expect most changes to be less tied to the IDE – and .NET Framework – version you’re using.
Understanding the releases
Now, let’s look at what we have, and kick it off with a timeline (click to enlarge):
.NET Framework – including the core of ASP.NET and Web Forms – has traditionally shipped in lockstep with Windows and Visual Studio. This still happens, but the interim releases play a growing role. Just look at the number of updates in the year since the Visual Studio 2012 launch!
The two key technologies that enable much of this are Web Platform Installer (WebPI) and NuGet. As you can see, they reached their current role in 2010-2011, and they have since become integral parts for upgrading and deploying things. Simplifying a bit, NuGet is your way to bring the newest stuff into your solution, and WebPI gets the infrastructure installed onto your development box and your production server.
In the aspConf keynote, the ASP.NET team promised updates to the platform every six months. Between Visual Studio 2012 and 2013, one year apart, they delivered ASP.NET and Web Tools 2012.2, thus completing the promise. This update was released separately in February 2013, but then later integrated into Visual Studio 2012 Update 2. Of course, these days you’re better off downloading Update 3 right away.
The next part of this blog post series will discuss the One ASP.NET vision further, but I’ll cover it briefly here.
As the diagram above illustrates, the idea is to have a single platform with multiple development technologies on it. Originally, ASP.NET was really marketed as Web Forms, and the idea of ASP.NET as a general platform was lost (on most developers at least) for years.
MVC was then tacked onto it, and alongside MVC 4 we saw the advent of Web API. Finally with the Web Tools 2012.2 update and its synchronized SignalR 1.0 release, we also have real-time communication built into the ASP.NET platform.
Additionally, project templates contain quite a few NuGet references since Visual Studio 2012. This enables you to get new versions of many of the libraries by simply pulling NuGet updates. At the time of writing, almost all of them have been updated at least once since the launch of VS2012.
Part three of this blog post series will touch on the tooling in more detail. But for now, I want to make one recommendation:
Install Visual Studio Web Essentials and learn it.
VSWE is a Microsoft-created Visual Studio plugin that was originally shipped in August 2012. It is intended to be the testing ground for new ideas in Visual Studio, and some of the features have already been merged from the plugin into the main IDE (in both VS 2012.2 and 2013 releases).
Since its original release, the plugin has evolved with a couple of dozen releases in the first year. In Build 2013 (June 2013), a preview of Visual Studio Web Essentials for Visual Studio 2013 was released.
There is so much stuff that it would take several blog posts to uncover it all, and there’s plenty of that around already. The picture above shows just a couple of simple features with CSS editing: Displaying the CSS colors as a small box beside the color definition, and IntelliSense for CSS3 animation names. But there’s so much more – check out the list for details.
The most important part of VSWE may not be its features though. While it’s definitely useful, I think its most fundamental impact is about being the preview of “What’s next for Visual Studio”. And while limited to the web editing part of VS, it’s still open source. Conceivably, contributing to VSWE might indirectly lead to you contributing to Visual Studio. Imagine how different that is from what we had five or ten years ago.
Get the source
As the diagram above already pointed out, many of ASP.NET’s key components are open source. Here is a summary for the state of the open source:
ASP.NET itself (the core, web forms etc.) is not really open source. Although you can access the source code as reference source, you’re governed by a specific license and only have access to released versions. This includes Web Forms.
ASP.NET MVC, Web API and Web Pages are open source with Apache license, and as of March 2012, they also accept contributions. They are available on the aspnetwebstack CodePlex site. The external contribution community isn’t very vibrant, but pull requests do happen.
SignalR has always been open source, and is hosted on its separate site in GitHub.
Web Essentials plugin was closed source for quite a while, but in Build 2013 the VS2013 version was open sourced in GitHub. I find this particularly relevant because the plugin gives an excellent practical example on extending Visual Studio – that alone makes this release a worthy example.
And finally, it’s worth mentioning that Entity Framework (a package included in many of the web project templates) is also open source. See my separate blog post on that.