Wondering when the ASP.NET MVC 4 and/or Web API Beta is going to drop? Wonder no more, today is the day!

Jon Galloway - ASP.NET MVC 4 Beta Released!

"Last September at //BUILD/ we announced ASP.NET MVC 4 Developer Preview. Today we're releasing the next release on the road to ASP.NET MVC 4, ASP.NET MVC 4 Beta. This release includes some great new features since the ASP.NET MVC 4 Developer Preview, including the introduction of ASP.NET Web API.

You can get all the info on ASP.NET MVC 4 at http://asp.net/mvc/mvc4

Here's an overview of what's new, and a quick reminder of some of the top features in ASP.NET MVC 4 in general.

ASP.NET Web API

The big new feature since the Developer Preview is the introduction of ASP.NET Web API.

ASP.NET Web API started out as WCF Web API. I've personally been a big fan of Web API - you may have seen my earlier post, WCF MediaTypeProcessor + Speech API = SpeechProcessor fun. I'm excited to see these merge together, as this brings a lot of power to Web API, unites programming models and removes the burden of having to choose between the two.

Why use ASP.NET Web API?

ASP.NET MVC was designed primarily for interacting with humans via web pages. The main use case is emitting HTML and responding to user input (submitting forms, clicking links, etc.). It does a great job at that.

• ASP.NET Web API
• Full Support For Routes
• Model Binding
• Filters
• Content Negotiation
• ASP.NET Web API Content
• Bundling by default
• Razor Enhancements
• URL Resolution - Support for ~/ syntax
• Conditional attribute rendering
• NuGet Based Project Installation

Software Requirements and Installation

The ASP.NET MVC 4 components for Visual Studio require PowerShell 2.0 and either Visual Studio 2010 with Service Pack 1 or Visual Web Developer Express 2010 with Service Pack 1. The ASP.NET MVC 4 Beta doesn't work with the Developer Previews of Visual Studio 11 or .NET 4.5. Stand by for those.

ASP.NET MVC 4 Beta runs side by side with previous versions of ASP.NET MVC. It's a pretty lightweight install - I've installed and uninstalled it lots of times without any impact on my other ASP.NET projects or Visual Studio in general.

You can install ASP.NET MVC 4 via Web PI or using the standalone installer executable - both are available at http://www.asp.net/mvc/mvc4

In the EULA (found at %ProgramFiles(x86)%\Microsoft ASP.NET\ASP.NET MVC 4\eula.rtf after install), you'll see that section 1a includes a Go Live license providing you meet the terms listed. I am not a lawyer, I am not a dentist, read the EULA, etc., but it does include this text: "If you comply with the rest of these license terms, you may also distribute to third parties or deploy for third parties to access over the Internet the ASP.NET programs that you develop using the software, provided that..."

Carlos' blog - Introducing ASP.NET MVC 4 Beta with Web APIs

There has historically been in Microsoft many ways of doing the same thing. That’s one of the original goals of WCF when it was created: unify the 5 or so different ways of creating distributed applications using the Microsoft stack (ASMX services, COM+, .NET Remoting, MSMQ and one more which I don’t remember). Whether it succeeded in making this unification is another story, but for a while the “official answer” for building distributed applications was WCF. XML was supposed to solve all the problems in the world, and WCF was a decent framework built on top of XML to build service-oriented solutions (i.e., SOAP) in a very pluggable way.

Fast forward a few years, XML didn’t bring world peace as it promised, and non-SOAP architectures started having a higher and higher predominance in the world, especially those revolving around HTTP and REST. Starting on the .NET Framework version 3.5, WCF started paying some attention to the HTTP/REST space with the introduction of the WebHttpBinding and WebHttpBehavior classes, the System.ServiceModel.Web namespace and the whole Web programming model. On the version 4.0, a lot more features were added to the framework, which collectively were called WCF Web HTTP Services. Starting at the end of 2010, the WCF Codeplex project started previewing new features which would eventually be made into the framework, which evolved into the WCF Web API project and the new HTTP programming model.

Backtracking a little, Microsoft also had another way of building “services” for web clients, namely services which accepted a variety of parameters and returned JSON (natively consumed by JavaScript apps), which was the JsonResult class in the ASP.NET MVC framework. In fact, quite a few people have approached me and other people in Microsoft with a variant of the same question: if I’m building web services to be consumed by JavaScript clients, which one should I use, MVC controllers, WCF Web APIs or “plain old WCF”? That was a valid question, and internally we decided to merge the technologies so that we could get the best of both worlds. As was announced today, the ASP.NET Web APIs are available for download along with the ASP.NET MVC 4 Beta release.

What exactly does it mean? First, notice that there’s no WCF in the “official” name – if you’re building Web APIs hosted on IIS, WCF isn’t used at all. But, unlike “classic” ASP.NET MVC applications, Web APIs can also be hosted outside of IIS (or self-hosted), in which case WCF is used as the underlying transport channel. So if you’re used to WCF (or the “old” WCF Web APIs), you may need to learn some new terminology. Some changes are simple, some are a little deeper.

• Goodbye Services and Operations, Hello Controllers and Actions
• Model binding
• More features

There are a lot of new features in the new APIs, some of them I’ll briefly mention here (and will possibly cover them in future posts)

• First-class HTTP support: don’t want to use CLR types? No problem. Your actions can work directly on HttpRequestMessage and HttpResponseMessage objects.
• Content-negotiation: out-of-the-box support for negotiation of response content, using formatters (similar to the last preview bits of the WCF Web API)
• HttpClient: a modern HTTP client for .NET. Henrik Nielsen (an architect in our team) has posted some examples of this library
• Service resolver: a centralized place to do things such as dependency injection
• System.Json: first-class support for treating JSON in an untyped way, without needing to serialize / deserialize between that format and CLR types
• Improved testability: as a side-effect of the HttpClient library and the service resolver; it’s possible to “host” a controller and send requests to it directly, without going through the network at all
• Query composition: support for actions returning IQueryable<T> and sending filter / take / skip / order parameters in the query string which affect how the response is returned
• Filters: something similar to inspectors in WCF, where you can hook up user code in various parts of a request dispatching
• Message handlers: I’d say that they’re similar to channels in WCF where you can get messages passing through the system, but that’s a disservice to the handlers. Channels in WCF are almost impossible to write, while message handlers are actually quite easy (once you get acquainted to the new Task asynchronous programming model)

..."

The Web API looks interesting. As is it's move away, in a sense, from WCF...