At installation, the just-released Visual Studio 2012 product installs .NET Framework 4.5, which incorporates brand new versions of ASP.NET Web Forms and ASP.NET MVC. For inscrutable reasons, ASP.NET Web Forms is versioned as 4.5, whereas the ASP.NET MVC you get with Visual Studio 2012 is verisoned as MVC 4.

Visual Studio 2012 brings new powerful tools such as Page Inspector, improved JavaScript and HTML editors, and the CSS editor (see Figure 1).

Figure 1: The new CSS editor in Visual Studio 2012.

As for the new API, the official list of new features in ASP.NET 4.5, related to both ASP.NET Web Forms and ASP.NET MVC, is readily available, but Table 1 offers a quick summary. Not all of the new features have the same impact on how you do things. I will look at the features from Table 1 that everybody should seriously consider when writing ASP.NET 4.5 applications. These features will make your ASP.NET programming in Visual Studio 2012 much different from the past

Table 1. What's new in ASP.NET 4.5.

Creating Your Own Web API

Most client applications require a back end accessible via simple HTTP calls. Whether it is a desktop or mobile application or just an Ajax-based HTML page, a list of HTTP endpoints is necessary for the app to download data and push requests. Until a few years ago, this was the territory of SOAP-based Web services and then WCF services. WCF is a great and powerful technology, but when all you need is to expose a few endpoints over HTTP and accept and return JSON data, WCF is often overkill. All attempts at adapting the WCF stack to a simpler HTTP-based conversation failed to win over developers.

Developers using ASP.NET MVC solved the problem by creating ad hoc controllers and route configuration. In this way, they could manage to handle any HTTP verb over handmade URL formats — an easy, lightweight, and especially effective solution. Up until ASP.NET 4.5, however, Web Forms developers had to stick to WCF services or tricky workarounds such as ASP.NET page methods. The new ASP.NET Web API comes to the rescue and provides a unique framework that works the same for both flavors of ASP.NET.

To use the Web API in ASP.NET MVC, you just add a new controller class and make it inherit from the new class ApiController.

public class OrdersController : ApiController
{
   public IList<OrderForDisplay> GetAll()
   {
       // Select all orders and return. Orders are packaged into data-transfer 
       // objects and include only properties required for display.
   }
   public OrderForDisplay Get(int orderId)
   {
       // Select specified order and return.
   }
   :
}

Unlike a canonical ASP.NET MVC controller, this class returns direct data instead of ActionResult objects. The base class ApiController takes care of all the plumbing necessary to make this code work on top of the ASP.NET MVC stack.

In addition, you need to add a new route that specifically targets the new API controller. You do this in global.asax:

routes.MapHttpRoute(    
    name: "DefaultApi",    
    routeTemplate: "api/{controller}/{id}",    
    defaults: new { id = RouteParameter.Optional }
);

In light of this, you can now use a URL, such as /orders or /orders/123, to get all orders or just a particular one. Furthermore, you can populate the API controller with methods bound to PUT, DELETE, and POST verbs. Verb binding is ruled by naming convention, and the methods Put, Delete, or Post are automatically associated with requests over the corresponding HTTP verb:

public class OrdersController : ApiController
{
    :
   // Sample URL: /orders
   public void Post(OrderForStore order)
   {
       // Use this to update/insert uploaded data
   }

   // Sample URL: /orders/123
   public void Put(int id, OrderForStore order)
   {
       // Use this to insert uploaded data
   }

   // Sample URL: /orders/123
   public void Delete(int id)
   {
       // Use this to delete uploaded data
   }
}

While this code is slightly simpler than you'd use with a canonical controller, it has the same effect. In ASP.NET MVC, the Web API is sometimes preferable over plain controllers because of one extra feature — content negotiation. Content negotiation refers to different clients requesting the same data in multiple formats such as JSON or XML. The Web API automatically looks at HTTP Accept headers and determines the ideal representation format for the requested content. Next, it checks whether the Web application lists an appropriate formatter capable of transforming raw content in the right response format. In this way, content negotiation becomes a matter of configuration on both the client and server side and no extra code is required.

To use the Web API in ASP.NET Web Forms, you add the same controller class (for example, OrdersController) to the App_Code project folder and edit global.asax in the same way. Presto! Now you also have a lightweight HTTP-based backend for your Web Forms application.