Blog Posts from May 2011 (page 1 of 1)

Using Task<T> in ASP.NET MVC Today

I’ve been experimenting with the new async support coming in the next version of C# (and VB). I must say, I’m very impressed. Async is one of those things you know you’re supposed to be doing. However, traditionally it has taken a lot of code and been hard to get right. The new await keyword changes all that.

For example, here’s an async function to download the Twitter public timeline:

public async Task PublicTimelineAsync()
{
  var url = "http://api.twitter.com/1/statuses/public_timeline.xml";
  var xml = await new WebClient().DownloadStringTaskAsync(url);
  return XDocument.Parse(xml);
}

That’s not much more difficult that writing the synchronous version. By using the new async and await keywords, all the ugly async CPS code you’re supposed to write is generated for you automatically by the compiler. That’s a huge win.

The only downside to async is that support for it is spotty in the .NET Framework today. Each major release of .NET to date has introduced a new async API pattern. .NET 1.0 had the Async Programming Model (APM). .NET 2.0 introduced the Event-based Async Pattern (EAP). Finally .NET 4.0 gave us the Task Parallel Library (TPL). The await keyword only works with APIs writen using the TPL pattern. APIs using older async patterns have to be wrapped as TPL APIs to work with await. The Async CTP includes a bunch of extension methods that wrap common async APIs, such as DownloadStringTaskAsync from the code above.

The async wrappers are nice, but there are a few places where we really need the TPL pattern plumbed deeper. For example, ASP.NET MVC supports AsyncControllers. AsyncControllers are used to avoid blocking IIS threads waiting on long running I/O operations – such as getting the public timeline from Twitter. Now that I’ve been bitten by the async zombie virus, I want to write my async controller methods using await:

public async Task<ActionResult> Index()
{
    var t = new Twitter();
    var timeline = await t.PublicTimelineAsync();
    var data = timeline.Root.Elements("status")
        .Elements("text").Select(e => e.Value);
    return View(data);
}

Unfortunately, neither the main trunk of MVC nor the MVC futures project has support for the TPL model [1]. Instead, I have to manually write some semblance of the async code that await would have emitted on my behalf. In particular, I have to manage the outstanding operations, implement a continuation method and map the parameters in my controller manually.

public void IndexAsync()
{
    var twitter = new Twitter();

    AsyncManager.OutstandingOperations.Increment();
    twitter
        .PublicTimelineAsync()
        .ContinueWith(task =>
        {
            AsyncManager.Parameters["timeline"] = task.Result;
            AsyncManager.OutstandingOperations.Decrement();
        });
}

public ActionResult IndexCompleted(XDocument timeline)
{
    var data = timeline.Root.Elements("status")
        .Elements("text").Select(e => e.Value);
    return View(data);
}

I promise you, writing that boilerplate code over and over gets old pretty darn quick. So I wrote the following helper function to eliminate as much boilerplate code as I could.

public static void RegisterTask<T>(
    this AsyncManager asyncManager,
    Task<T> task,
    Func<T, object> func)
{
    asyncManager.OutstandingOperations.Increment();
    task.ContinueWith(task2 =>
    {
        //invoke the provided function with the
        //result of running the task
        var o = func(task2.Result);

        //use reflection to set asyncManager.Parameters
        //for the returned object's fields and properties
        var ty = o.GetType();
        foreach (var f in ty.GetFields())
        {
            asyncManager.Parameters[f.Name] = f.GetValue(o);
        }
        foreach (var p in ty.GetProperties())
        {
            var v = p.GetGetMethod().Invoke(o, null);
            asyncManager.Parameters[p.Name] = v;
        }

        asyncManager.OutstandingOperations.Decrement();
    });
}

With this helper function, you pass in the Task<T> that you are waiting on as well as a delegate to invoke when the task completes. RegisterTask takes care of incrementing and decrementing the outstanding operations count as appropriate. It also registers a continuation that reflects over the object returned from the invoked delegate to populate the Parameters collection.

With this helper function, you can write the async controller method like this:

public void IndexAsync()
{
    var twitter = new Twitter();

    AsyncManager.RegisterTask(
        twitter.PublicTimelineAsync(),
        data => new { timeline = data });
}

//IndexCompleted hasn't changed
public ActionResult IndexCompleted(XDocument timeline)
{
    var data = timeline.Root.Elements("status")
        .Elements("text").Select(e => e.Value);
    return View(data);
}

It’s not as clean as the purely TPL based version. In particular, you still need to write separate Async and Completed methods for each controller method. You also need to build an object to map values from the completed tasks into parameters in the completed method. Mapping parameters is a pain, but the anonymous object syntax is terser than setting values in the AsyncManager Parameter collection.

It’s not full TPL support, but it’ll do for now. Here’s hoping that the MVC team has async controller methods with TPL on their backlog.


[1] I’m familiar with Craig Cavalier’s Async MVC with TPL post, but a fork of the MVC Futures project is a bit too bleeding edge for my needs at this point.

Build Your Own WDS Discovery Image

Given that I work on the Windows team, it shouldn’t come as a surprise that we use Windows Deployment Services to distribute Windows images internally. For most machines, it’s really convenient. You trigger a network boot (on my Lenovo, you press the “ThinkVantage” button during start up), select the image to install and what partition to install it to, wait a while, answer the installation finalization questions (machine name, user name, etc) and you’re done.

However, I have an Dell Inspiron Duo (with the cool flip screen) netbook that lacks a built in network port. No network port, no network boot. I’ve got a USB network dongle, but it doesn’t support network boot either. No network boot, no ultra-convenient WDS installation, sad DevHawk.

I was able to work around this by building a custom WDS Discover image that I loaded onto a USB flash drive. Now, I plug in the USB drive, select it as the boot device and I’m off and running…err, off and installing at any rate. Building the image was kind of tricky, so I figured it would be a good idea to write it down and share.

Step One: Install the Windows Automated Installation Kit (AIK)
The AIK is a set of tools for customizing Windows Images and deployment. In particular, it includes the Windows Preinstallation Environment (aka WinPE) which is the minimal OS environment that Windows Setup runs in. We’ll be building a custom WinPE image to launch the WDS discovery and setup from.

Step Two: Create a new PE image
The AIK includes a command line tool for creating a blank PE image. Step 1 of this walkthru shows you how to use it. It’s pretty easy. Open the Deployment Tools Command Prompt as an administrator and run the following commands:

copype.cmd x86 C:\winpe_x86
copy winpe.wim ISO\sources\boot.wim

The copype.cmd batch file creates a new PE image of the specified architecture in the specified location. The Inspiron is an Atom processor so I chose an x86 PE image.

Note, in several steps below I assume you’ve created your  PE image in c:\winpe_x86. If you’ve created it somewhere else, make sure to swap in the correct path when executing the steps below.

Step Three: Mount the PE Boot image with DISM
Now that we have our basic PE boot image, we need to update it with custom drivers and the setup experience that can load WDS images across the network. Before we can update boot.wim, we need to mount it on the file system.

The AIK includes the Deployment Image Servicing and Management (DISM) tool for working with WIM files. To mount the boot.wim file, execute the following command:

dism /Mount-WIM /WimFile:C:\winpe_x86\ISO\sources\boot.wim /index:1 /MountDir:c:\winpe_x86\mount

Copype.cmd created an empty mount directory specifically for DISM to mount WIM images in.

Step Four: Add Custom Device Driver
The driver for my USB network dongle is not included in the standard Windows driver package, so it needs to be manually added to the PE image. Again, we use DISM to do this.

dism /image:c:\winpe_x86\mount /add-driver /driver:"PATHTODRIVERDIRECTORY"

Step Five: Add Setup packages
The PE image does not include the Windows Setup program by default. There are several optional packages that you can add to your PE image. For WDS discovery, you need to add the setup and setup-client packages. Again, we use DISM to update the image.

dism /image:c:\winpe_x86\mount /add-package /packagepath:"c:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-setup.cab"
dism /image:c:\winpe_x86\mount /add-package /packagepath:"c:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-setup-client.cab"

Step Six: Add winpeshl.ini file
Now that we’ve added the setup program to the image, we need to tell setup to run in WDS discovery mode on startup. This is accomplished by adding a winpeshl.ini file to the WindowsSystem32 folder of the PE image.

Note, the official instructions on TechNet have a bug. The path to setup.exe should be %SYSTEMDRIVE%sources, not %SYSTEMROOT%sources. Here’s the contents of my winpeshl.ini file:

[LaunchApps]
%SYSTEMDRIVE%\sources\setup.exe, "/wds /wdsdiscover"

You can also add /wdsserver:<server> to the command line if you want to hard code the WDS Server to use in your image.

Step Seven: Add Lang.ini file
If you do all the above steps and try to boot the resulting image, you’ll get a nasty “Windows could not determine the language to use for Setup” error. Turns out there’s another bug in the official docs – you need a lang.ini file in your sources directory along side setup.exe in order to run. I just grabbed the lang.ini file off the normal Win7 boot image and copied it to the sources directory of my mounted boot image.

Step Eight: Commit and Unmount the PE Boot image
We’re now done updating the boot image, so it’s time to close and unmount it. This is accomplished with DISM:

dism /unmount-wim /mountdir:c:\winpe_x86\mount /commit

At this point, the contents of the ISO folder are ready to be transferred to a USB stick for booting.

Step Nine: Prepare the USB Flash Drive
To enable your USB flash drive to be bootable, it needs to have a single FAT32 partition spanning the entire drive. Instructions in this walkthru show you how to configure and format your USB drive.

Note, not all USB drives are created equal. I have one USB drive where the Duo just comes up with a blank screen when I try to use it for USB Boot. If you follow these steps and can’t boot, try a different USB drive.

Step Ten: Copy the image contents to the Flash Drive
I just did this with xcopy. In this case, my flash drive is E:, but obviously you should swap in the drive letter for your flash drive.

xcopy c:\winpe_x86\ISO\*.* /e e:

Step Eleven: Boot your Netbook from the USB drive
With the USB drive containing the image + the network dongle both plugged in, boot the machine and trigger USB boot. For the Duo, you can hit F12 during boot to manually select your boot source. Your custom image will be booted, and it will then look out on the network to find the WDS server to load images from. Select the image you want and where you want to install it and away you go.

One thing to remember is that you’re adding the  USB network dongle driver to the WDS discovery boot image, but not to the image that gets installed via WDS. So chances are you’ll need the driver again once you get the image installed. I put that driver on the same USB key that holds the boot image. That way I can easily install the driver once Windows is installed.