ASP.NET Web Tools 2012.2 Release Candidate

 Last Month, Microsoft released the ASP.NET and Web Tools 2012.2 update.  This release will extend the ASP.NET runtime a little bit and adds new tools to Visual Studio 2012. This update adds some new features and tools for all the flavors of ASP.NET (Web Forms, MVC, Web API, etc.).  I copied some of the highlights from the release marketing below.  It sounds pretty cool.

ASP.NET Enhancements
This update adds new ASP.NET templates and features, including:

• New ASP.NET MVC templates.
  • Creating Facebook applications just became easier using the new Facebook Application template. In just a few easy steps you can create a Facebook application that gets data from logged in users and integrates with their friends.
  • A new Single Page Application template allows developers to build interactive client-side web apps using Knockout, jQuery, and ASP.NET Web API.
• Real-time communication support with ASP.NET SignalR.  This enables you to easily take advantage of the new WebSocket support in .NET 4.5, while also automatically degrading to long-polling and other protocols for older clients.  If you haven’t tried SignalR yet you should – it is awesome.
• New ASP.NET Web API functionality, including support for OData, integrated tracing, and automatically generating help page documentation for your API.
• New ASP.NET Friendly URL functionality. This new feature makes it very easy for Web Forms developers to generate cleaner looking URLs (without the .aspx extension). The Friendly URLs feature also makes it easier for developers to add mobile support to their applications with support for mobile .ASPX pages and  supporting switching between desktop and mobile views.  It can be used with existing ASP.NET v4.0 applications.
• Visual Studio 2012 Web publishing enhancements. Web site projects now have the same publish experience as web application projects (including to Windows Azure Web Sites), and you can selectively publish files, see the differences between local and remote files, and update local to remote files or vice versa.
• Visual Studio 2012 Page Inspector enhancements. JavaScript selection mapping is now supported, and you can CSS updates in real-time.
• Visual Studio 2012 editor support for Knockout IntelliSense and pasting JSON as a .NET class (which makes it even easier to consume Web APIs from others).
• Visual Studio 2012 Project Template updates, including the latest versions of jQuery, jQuery UI, jQuery Validation, Modernirz, Knockout and more…

How it is delivered
You can download and install an integrated setup that contains the above enhancements today from http://www.asp.net/vnext.  The new runtime functionality is delivered to ASP.NET via additional NuGet packages. This means that installing this update does not make any changes to the existing ASP.NET binaries, and thus does not cause any compatibility issues with existing projects. New projects will contain the new functionality and existing projects can be updated with the new NuGet packages.

Summary
Web development is changing, and ASP.NET is rapidly delivering new capabilities to developers that help them take full advantage of new capabilities.  The ASP.NET and Web Tools 2012.2 update installs in minutes without altering the current ASP.NET run time components.  For a complete description see the Release Notes.

You can download and install the RC today: http://www.asp.net/vnext.

Async in C#

C# 5 adds some powerful asynchronous functionality as an expansion to the Task and Task<TResult> aspects of .NET 4.  The old model seemed to focus on the Asynchronous Pattern and the Event-based Asynchronous Pattern but the framework itself didn't bring much to the table for allowing developers with varied levels of knowledge access to an easily adopted methodology.  With the roll out of C# 5, .NET has provided us with a wrapped API for all asynchronous programming via library based method calls.  This is the first building block of the new features for asynchronous programming and it has been said that going forward, all asynchronous operations will work via a method that returns Task or Task<TResult>.

A key change for this version is the addition of the async keyword.  This contextual keyword enables an easy declaration of an asynchronous function. Note that all asynchronous functions must return either void, a Task, or a Task<T>.  When declaring a function with async, it is also required that there must be at least one await expression inside the function itself. 

The await keyword expression does not block the thread on which it is executing. Instead, it causes the compiler to sign up the rest of the async method as a continuation on the awaited task. Control then returns to the caller of the async method. When the task completes, it invokes its continuation, and execution of the async method resumes where it left off. An await expression can occur only in the body of an immediately enclosing method, lambda expression, or anonymous method that is marked by an async modifier. The term await serves as a keyword only in that context. Elsewhere, it is interpreted as an identifier. Within the method, lambda expression, or anonymous method, an await expression cannot occur in the body of a synchronous function, in a query expression, in the catch or finally block of an exception handling statement, in the block of a lock statement, or in an unsafe context.

// Keyword await used with a method that returns a Task&ltresult&gt.
TResult result = await AsyncMethodThatReturnsTaskTResult();

// Keyword await used with a method that returns a Task.
await AsyncMethodThatReturnsTask();

Here is a simple example, suppose we want to download a webpage as a string so we can check to see if it supports XHTML 1.0,. There is a new method added to WebClient: Task<string> WebClient.DownloadStringTaskAsync(Uri).  Since this returns a Task<string> we can use it within an asynchronous function. We could do this entire process with jsut a few lines of code.

private void button1_Click(object sender, RoutedEventArgs e)
{
   String url = "http://devstorm.blogspot.com";
   String content = await new WebClient().DownloadStringTaskAsync(url);
   textBox1.Text = String.Format("Page {0} supports XHTML 1.0: {1}",
      url, content.Contains("XHTML 1.0"));
}

By adding the async contextual keyword to the method definition, we are able to use the await keyword on our WebClient.DownloadStringTaskAsync method call. This means that when the user clicks the new method (Task<string> WebClient.DownloadStringTaskAsync(string)) is called.  By adding the await keyword, the runtime will call this method that returns Task<string> and execution will return to the UI.  This means that our UI is not blocked while the webpage is downloaded.  Instead, the UI thread will “await” at this point, and let the WebClient do it’s thing asynchronously.  When the WebClient finishes downloading the string, the user interface’s synchronization context will automatically be used to “pick up” where it left off, and the Task<string> returned from DownloadStringTaskAsync is automatically unwrapped and set into the content variable, thus allowing us to report it in the text box.

Notice how the code is obviously shorter and simpler because the initial synchronization context is used to continue the execution of this function.  Meaning,  we don’t have to explicitly marshal the call that sets textbox1.Text back to the UI thread, it is just picked up via the framework.  This sort of abstraction of the difficulty is a strong step toward enabling a wide range of developers the ability to leverage asynchronous programming.  The will ultimately, as always, result in better software for the users.

Web API in ASP.NET MVC4

In the new version of ASP.NET, Microsoft has introduced some framework extension that has exciting possibilities.  Google, FaceBook, and the like have been exposing web API in some fashion for a while now, but it has always seemed limited to certain platforms.  It appears at a glance that we will be able to provide the same functionality with native ASP.NET and MVC4 applications.  This basically allows you to expose web service over straight up HTTP instead of traditional service hosting/messaging.

The gain is that you can create web-based integration points by leveraging  a native ASP.NET architecture at the same time.  This allows you to provide a user-story-based integration routine (ala FaceBook, Twitter) as a wrapper of /or in addition to any service layer integrations that may be exposed.  

Here are some points I read from Scott Gu's Blog on the topic.  He outlines the highlights and additions to the framework.  I think the real excitement is in the realization of the walls that are coming down on platform dependence and ease of developing rich client experiences with web services in a Windows environment.

Our new ASP.NET Web API support enables you to easily create powerful Web APIs that can be accessed from a broad range of clients (ranging from browsers using JavaScript, to native apps on any mobile/client platform).  It provides the following support:

• Modern HTTP programming model: Directly access and manipulate HTTP requests and responses in your Web APIs using a clean, strongly typed HTTP object model.  In addition to supporting this HTTP programming model on the server, we also support the same programming model on the client with the new HttpClient API that can be used to call Web APIs from any .NET application.

• Content negotiation: Web API has built-in support for content negotiation – which enables the client and server to work together to determine the right format for data being returned from an API.  We provide default support for JSON, XML and Form URL-encoded formats, and you can extend this support by adding your own formatters, or even replace the default content negotiation strategy with one of your own.

• Query composition: Web API enables you to easily support querying via the OData URL conventions.  When you return a type of IQueryable<T> from your Web API, the framework will automatically provide OData query support over it – making it easy to implement paging and sorting.

• Model binding and validation: Model binders provide an easy way to extract data from various parts of an HTTP request and convert those message parts into .NET objects which can be used by Web API actions.  Web API supports the same model binding and validation infrastructure that ASP.NET MVC supports today.

• Routes: Web APIs support the full set of routing capabilities supported within ASP.NET MVC and ASP.NET today, including route parameters and constraints. Web API also provides smart conventions by default, enabling you to easily create classes that implement Web APIs without having to apply attributes to your classes or methods.  Web API configuration is accomplished solely through code – leaving your config files clean.

• Filters: Web APIs enables you to easily use and create filters (for example: [authorization]) that enable you to encapsulate and apply cross-cutting behavior.

• Improved testability: Rather than setting HTTP details in static context objects, Web API actions can now work with instances of HttpRequestMessage and HttpResponseMessage – two new HTTP objects that (among other things) make testing much easier. As an example, you can unit test your Web APIs without having to use a Mocking framework.

• IoC Support: Web API supports the service locator pattern implemented by ASP.NET MVC, which enables you to resolve dependencies for many different facilities.  You can easily integrate this with an IoC container or dependency injection framework to enable clean resolution of dependencies.

• Flexible Hosting: Web APIs can be hosted within any type of ASP.NET application (including both ASP.NET MVC and ASP.NET Web Forms based applications).  We’ve also designed the Web API support so that you can also optionally host/expose them within your own process if you don’t want to use ASP.NET/IIS to do so.  This gives you maximum flexibility in how and where you use it.

jQueryUI and ASP.NET Master Pages

Here is cool trick to save some time when using jQueryUI and ASP.NET with master pages. The thing that always seems to trip someone up is finding a control from the master page and trying to hit it with a jQuery call. When ASP.NET adds a control to the DOM and you are using master pages, the ID is actually changed from what you assigned in the designer. It seems to be fairly random and shouldn't be counted on for consistency or convention, aside from all of the randomness preceding the ID from the designer. After piddling around for a while, I did find something that will work. Consider the following code (This code assumes you have all of your links and css hooked up.):

<script type="text/javascript">

$(function ()

{           

  $('[id$=txtCal]').datepicker({

     showOn: "button",

     buttonImage: "../images/calendar16.png",

     buttonImageOnly: true,

     buttonText: 'Choose'

   }); 

}

</script>

By using the jQuery "ends with" selector ($=) I am able to find any control with an ID. So, by using this master page, ANY control that has an ID ending with 'txtCal' will be formatted to be a drop down calendar using jQueryUI. By using this sort of approach and following consistent naming conventions, you would be able to do most of your UI changes from your master pages, allowing for consistent theme style control over their implementation. This also opens the door for driving more jQuery behavior from the the master page.

Visual Studio IDE Performance

Here are a few tips I found online for speeding up Visual Studio 2010 day to day while working.

Faster builds by unloading projects

A quick way to speed up your build process is to unload up-to-date projects that you are not working on at the current time. Just right-click the project in the Solution Explorer and choose Unload.

Building / Running
When you debug an application Visual Studio compiles the projects, then launches the project and attaches it to the debugger. You can lower the number of projects that Visual Studio builds during this process by checking the "Only Build startup projects and dependencies on Run" box under Tools|Options.

General IDE Stuff
By changing a couple of options in the code windows you may be able to speed up the IDE as far as just being responsive. You can try some of these and see what happens. They can save some time depending on how much you have open, etc.
* Disable Track Changes. (Tools\Options\Text Editor\General\Track changes)
* Disable Navigation Bar (Tools\Options\Text Editor\C#)
* Disable "Track Active Item in Solution Explorer" (Tools\Options\Projects and Solutions)
These switches are a trade-off sometimes. The track changes item will force you to manually navigate to your current file in the solution tree, etc.
Detect when file changes

In projects with tons of files, you can gain some speed by disabling the "Detect when file changes" option.
Start Screen

Visual Studio opens faster if you disable the start screen option. To disable the Start screen and just open to an empty environment, uncheck the "Show Page on startup" checkbox on the start page itself. This results in a pretty quick open.