1. Introduction
2. SynchronizationContext
3. ContinueWith
4. TaskHelpers

Simple Task Helpers

I know we left off in part 3 with a problem, but we're not going to solve it yet, because we still need to build some foundation helper classes that will make it easier to do that. In particular, there are some good practices we can codify around the creation and conversion of tasks that led us to write the TaskHelpers class that we use today in ASP.NET Web Stack.

Caching Tasks (and Disposability)

One of the important things to remember about TaskCompletionSource is that it can be somewhat expensive to create. If you look at the implementation of the async/await compiler feature, you'll see that they go to great lengths to cache a bunch of reusable tasks; we don't go quite as far, but we have at least centralized our creation of completed, canceled, and faulted tasks so that we can improve this caching logic as time goes on, as we see fit.

You might've noticed that the Task class implements IDisposable; doesn't that mean you should dispose it when you're done with it? Wouldn't that invalidate all this caching work? It turns out the answer is not so simple; the truth is that it's often impossible to know who the true owner of a task is. Stephen Toub, the architect behind the Task Parallel Library, argues that you should not dispose your Task objects, and his work with the compiler team to enable their caching behavior in .NET 4.5 is the ultimate validation of this argument. Resist the temptation: do not dispose your Task!

Canceled Tasks

The first and easiest helpers to show are for the creation of canceled tasks. These are also the easiest thing to cache, since they have no state, so we also get to show how caching might work for the more complex versions.

public static class TaskHelpers
{
    public static Task Canceled()
    {
        return CancelCache<AsyncVoid>.Canceled;
    }

    public static Task<TResult> Canceled<TResult>()
    {
        return CancelCache<TResult>.Canceled;
    }
}

static class CancelCache<TResult>
{
    public static readonly Task<TResult> Canceled
        = GetCancelledTask();

    static Task<TResult> GetCancelledTask()
    {
        var tcs = new TaskCompletionSource<TResult>();
        tcs.SetCanceled();
        return tcs.Task;
    }
}

struct AsyncVoid { }

We are taking advantage of the static initialization facilities of the C# language, combined with generics, to get a create-on-demand, cached-for-app-lifetime canceled task.

You'll notice that I'm using a private struct (AsyncVoid) as a stand-in to represent the T for our cancel cache. We could have just as easily used any other type, but my feeling here is that it should be trivial to look at some Task object which is-a Task<T> and know whether it was purposefully or accidentally casted down to Task. Perhaps just as importantly, there is no non-generic version of TaskCompletionSource, so not having the result be a Task<T> was kind of out of the question.

Completed Tasks

Our next task creation helper is around completed tasks. Here, we do a small amount of caching for completed Task, as well as a completed Task<object> which returns null. The compiler in .NET 4.5 is much more aggresive about pre-computing and caching completed tasks with common return values; we could do the same thing at some point in the future if we so desired, since we funnel all our helpers through here.

public static class TaskHelpers
{
    static readonly Task<object> _completedTaskReturningNull
        = FromResult<object>(null);

    static readonly Task _defaultCompleted
        = FromResult<AsyncVoid>(default(AsyncVoid));

    public static Task Completed()
    {
        return _defaultCompleted;
    }

    public static Task<TResult> FromResult<TResult>(
        TResult result)
    {
        var tcs = new TaskCompletionSource<TResult>();
        tcs.SetResult(result);
        return tcs.Task;
    }

    public static Task<object> NullResult()
    {
        return _completedTaskReturningNull;
    }
}

Faulted Tasks

The final kind of task creation we need to support is faulted tasks. There is really no opportunity for caching here, since the exception objects will be different every time. Note that there are two versions here, one which takes a single exception and one which takes many exceptions; the latter is useful when you're aggregating the results of several faulted tasks together.

public static class TaskHelpers
{
    public static Task FromError(
        Exception exception)
    {
        return FromError<AsyncVoid>(exception);
    }

    public static Task<TResult> FromError<TResult>(
        Exception exception)
    {
        var tcs = new TaskCompletionSource<TResult>();
        tcs.SetException(exception);
        return tcs.Task;
    }

    public static Task FromErrors(
        IEnumerable<Exception> exceptions)
    {
        return FromErrors<AsyncVoid>(exceptions);
    }

    public static Task<TResult> FromErrors<TResult>(
        IEnumerable<Exception> exceptions)
    {
        var tcs = new TaskCompletionSource<TResult>();
        tcs.SetException(exceptions);
        return tcs.Task;
    }
}

Run Synchronously

Calling Task.Factory.StartNew when you don't actually need to do anything asynchronously can be expensively wasteful, because it's likely to spin up a worker thread and cause a thread switch to run your inherently synchronously code. We have several overloads of RunSynchronously which can be used to get Task objects which are already completed and contain the result of the synchronous code. These functions also accept cancellation tokens, and return canceled tasks when the token is signaled; they also take advantage of our previous helper methods to get caching benefits.

public static class TaskHelpers
{
    public static Task RunSynchronously(
        Action action,
        CancellationToken token = default(CancellationToken))
    {
        if (token.IsCancellationRequested)
            return Canceled();

        try
        {
            action();
            return Completed();
        }
        catch (Exception e)
        {
            return FromError(e);
        }
    }

    public static Task<TResult> RunSynchronously<TResult>(
        Func<TResult> func,
        CancellationToken token = default(CancellationToken))
    {
        if (token.IsCancellationRequested)
            return Canceled<TResult>();

        try
        {
            return FromResult(func());
        }
        catch (Exception e)
        {
            return FromError<TResult>(e);
        }
    }

    public static Task<TResult> RunSynchronously<TResult>(
        Func<Task<TResult>> func,
        CancellationToken token = default(CancellationToken))
    {
        if (token.IsCancellationRequested)
            return Canceled<TResult>();

        try
        {
            return func();
        }
        catch (Exception e)
        {
            return FromError<TResult>(e);
        }
    }
}

Copying Task Results to TaskCompletionSource

The final bit of helpers for this post are a few extension methods for TaskCompletionSource which can be used to partially or fully copy the results of a task onto the completion source. These helpers only set the results if the task is currently complete; they don't wait for the task to complete if it has not already done so.

public static class TaskHelpers
{
    public static bool TrySetFromTask<TResult>(
        this TaskCompletionSource<TResult> tcs,
        Task source)
    {
        if (source.Status == TaskStatus.Canceled)
            return tcs.TrySetCanceled();

        if (source.Status == TaskStatus.Faulted)
            return tcs.TrySetException(
                source.Exception.InnerExceptions);

        if (source.Status == TaskStatus.RanToCompletion)
        {
            var tr = source as Task<TResult>;
            return tcs.TrySetResult(
                tr == null
                    ? default(TResult)
                    : tr.Result);
        }

        return false;
    }

    public static bool TrySetFromTask<TResult>(
        this TaskCompletionSource<Task<TResult>> tcs,
        Task source)
    {
        if (source.Status == TaskStatus.Canceled)
            return tcs.TrySetCanceled();

        if (source.Status == TaskStatus.Faulted)
            return tcs.TrySetException(
                source.Exception.InnerExceptions);

        if (source.Status == TaskStatus.RanToCompletion)
        {
            // Sometimes the source is Task<Task<TResult>>,
            // and sometimes it's Task<TResult>. Handle both.

            var ttr = source as Task<Task<TResult>>;
            if (ttr != null)
                return tcs.TrySetResult(ttr.Result);

            var tr = source as Task<TResult>;
            if (tr != null)
                return tcs.TrySetResult(tr);

            return
                tcs.TrySetResult(
                    FromResult(default(TResult)));
        }

        return false;
    }

    public static bool TrySetIfFailed<TResult>(
        this TaskCompletionSource<TResult> tcs,
        Task source)
    {
        switch (source.Status)
        {
            case TaskStatus.Canceled:
            case TaskStatus.Faulted:
                return tcs.TrySetFromTask(source);
        }

        return false;
    }
}

What's Next?

We've got a firm understanding of the fundamentals, and built up all the necessary infrastructure, so now we're ready to start writing our replacement helpers for the existing Task methods; in particular, we will be looking to completely replace the usage of ContinueWith with safer, targeted, a better performing helper methods.

1. Introduction
2. SynchronizationContext
3. ContinueWith
4. TaskHelpers

What ContinueWith Really Does

I promised that we had a bug in our previous code, and we did... sort of. Calling ContinueWith without any special flags will cause your continuation to always run, regardless of the final state of the task. We wrote our continuation under the assumption that the Task had completed successfully, which can lead to some very odd and hard to debug problems. Luckily, in our code, we ended up calling Result on the Task object, which turns around and throws an exception if the task had ended in a faulted or canceled state. But what if we'd had a Task rather than a Task<T>? Or what if we hadn't called Result? In .NET 4, this is considered a fatal error condition, and when the task object got garbage collected, its finalizer would've thrown an exception that takes down your AppDomain because you had an unobserved fault! Definitely not good.

That means that we always need to make sure to check the task's status, and if it's faulted, make sure we access the Error property of the task object so that it knows we observed the fault. That's probably a good thing to do, even if we know we're going to touch Result, because it means we get to observe the exception without causing it to be thrown again, and we definitely want to keep unnecessary exceptions to a minimum.

Unobserved Faulted Tasks in .NET 4 vs. 4.5

A quick side-note: this "killing the AppDomain because an unobserved faulted task" behavior is unique to .NET 4; it was removed from .NET 4.5. This is because all Task-based programming in .NET 4 was about explicitly returning a Task object. When the team added the async and await keywords to .NET 4.5, they also enabled async methods to return void. They discovered that there was a very useful place for void-returning async methods: as event handlers in UI applications. Since the method returns void, there's no way for the caller to know (or care) that the method they called actually spun off async work to be done; as such, it could no longer be the case that unobserved faults should be an application failure.

That said, these event handlers in client UI applications may be good candidates for void-returning async methods; however, you must never use such a method in server event handling (for example, when handling a WebForms event) when the client needs to wait for the result. The event handler that calls your callback has no way of knowing that you have some async work to be done and that it should wait for you to finish, so of course the client will get its response before your work is complete.

Performance Optimizations

One more thing we can do with our continuation work is to avoid calling ContinueWith at all. This has two potential benefits:

1. We can avoid the potential thread hop that comes with ContinueWith;
2. We can avoid allocating an extra Task object when not needed.

Both of these reasons are good reasons why we should consider helpers for ContinueWith when running on servers.

Revising Our ContinueWith Example

Let's start with our example from part 2:

var ctxt = SynchronizationContext.Current;

return SomeThingReturningATask()
      .ContinueWith(innerTask =>
{
    var tcs = new TaskCompletionSource<int>();

    try
    {
        if (ctxt != null)
        {
            ctxt.Post(state =>
            {
                try
                {
                    int result = innerTask.Result;
                    tcs.TrySetResult(result);
                }
                catch(Exception ex)
                {
                    tcs.TrySetException(ex);
                }
            }, state: null);
        }
        else
        {
            int result = innerTask.Result;
            tcs.TrySetResult(result);
        }
    }
    catch(Exception ex)
    {
        tcs.TrySetException(ex);
    }

    return tcs.Task;
});

Let's extract a helper function out of this:

static Task<TOut> Continue(
        this Task<TIn> task,
        Func<Task<TIn>, TOut> next)
{
    var tcs = new TaskCompletionSource<TOut>();
    var ctxt = SynchronizationContext.Current;

    task.ContinueWith(innerTask =>
    {
        try
        {
            if (ctxt != null)
            {
                ctxt.Post(state =>
                {
                    try
                    {
                        var res = next(innerTask);
                        tcs.TrySetResult(res);
                    }
                    catch(Exception ex)
                    {
                        tcs.TrySetException(ex);
                    }
                }, state: null);
            }
            else
            {
                var res = next(innerTask);
                tcs.TrySetResult(res);
            }
        }
        catch(Exception ex)
        {
            tcs.TrySetException(ex);
        }
    });

    return tcs.Task;
}

This is the same code as we had above, but now we just call this with a very simple lambda, and all the work is done on our behalf:

return SomeThingReturningATask()
      .Continue(innerTask => innerTask.Result * 42);

The helper is taking care of the transition to the sync context automatically for us. Now as we add new capabilities to this helper function, we reap the benefits everywhere we're using it.

Removing ContinueWith

The next optimization we want to do is remove the call to ContinueWith entirely if the task we've been given is already completed. This prevents us from hopping onto a new thread to get the work done. In a stack like Web API which has been designed from top to bottom to be async, it turns out that most everything we do completes synchronously, because on the server there are very few reasons to actually wait (remember, we know that we shouldn't thread-hop just to compute something, so our opportunities for async on a server are usually around long-running I/O operations).

If we re-work our example to avoid unnecessary calls to ContinueWith, then it might look something like this:

static Task<TOut> Continue(
        this Task<TIn> task,
        Func<Task<TIn>, TOut> next)
{
    var tcs = new TaskCompletionSource<TOut>();
    var ctxt = SynchronizationContext.Current;

    if (task.IsCompleted)
    {
        try
        {
            var res = next(innerTask);
            tcs.TrySetResult(res);
        }
        catch(Exception ex)
        {
            tcs.TrySetException(ex);
        }
    }
    else
    {
        task.ContinueWith(innerTask =>
        {
            try
            {
                if (ctxt != null)
                {
                    ctxt.Post(state =>
                    {
                        try
                        {
                            var res = next(innerTask);
                            tcs.TrySetResult(res);
                        }
                        catch(Exception ex)
                        {
                            tcs.TrySetException(ex);
                        }
                    }, state: null);
                }
                else
                {
                    var res = next(innerTask);
                    tcs.TrySetResult(res);
                }
            }
            catch(Exception ex)
            {
                tcs.TrySetException(ex);
            }
        });
    }

    return tcs.Task;
}

In our task.IsCompleted block, notice that I don't bother with the sync context. That's because we're staying on the same thread, so the sync context will be the same. We also have three potential threads of execution in here (the main function body, plus the two lambdas) so we have three try/catch handlers, converting exceptions into faulted tasks.

Lambdas and Closures

There is one final bit of optimization left to be done. Now that we have a block of code which calls ContinueWith and a block of code that doesn't, we should be paying close attention to whether our lambda functions are actually closures.

A closure is a special kind of lambda that has access to the local variables and parameters of the function that it's inside of, even after that function has exited. If you look closely at our call to ContinueWith, you'll see that we are in fact writing a closure, because we use the next parameter as well as the tcs and ctxt variables inside the lambda. If we were diligent, we could get rid of tcs, but we're stuck with the others.

When the compiler generates a closure, it does so by making a tiny object with the state inside of it. Unfortunately, when the compiler realizes that you've got a closure anywhere in your method, it does all the work up front of allocating the state object, even if you never end up using the closure (and if you have two closures, that state object ends up being a combination of the shared values between both closures). When you see code like this which is only sometimes using a closure, it's common to split it up into the non-closure part vs. the closure part.

Let's iterate one more time on the helper function:

static Task<TOut> Continue(
        this Task<TIn> task,
        Func<Task<TIn>, TOut> next)
{
    if (task.IsCompleted)
    {
        var tcs = new TaskCompletionSource<TOut>();

        try
        {
            var res = next(innerTask);
            tcs.TrySetResult(res);
        }
        catch(Exception ex)
        {
            tcs.TrySetException(ex);
        }

        return tcs.Task;
    }

    return ContinueClosure(task, next);
}

static Task<TOut> ContinueClosure(
        Task<TIn> task,
        Func<Task<TIn>, TOut> next)
{
    var ctxt = SynchronizationContext.Current;

    return task.ContinueWith(innerTask =>
    {
        var tcs = new TaskCompletionSource<TOut>();

        try
        {
            if (ctxt != null)
            {
                ctxt.Post(state =>
                {
                    try
                    {
                        var res = next(innerTask);
                        tcs.TrySetResult(res);
                    }
                    catch(Exception ex)
                    {
                        tcs.TrySetException(ex);
                    }
                }, state: null);
            }
            else
            {
                var res = next(innerTask);
                tcs.TrySetResult(res);
            }
        }
        catch(Exception ex)
        {
            tcs.TrySetException(ex);
        }

        return tcs.Task;
    }).Unwrap();
}

We've split the work into two functions, and we've moved the allocation of the TaskCompletionSource inside the closure. We still have next and ctxt in the closure, but there's nothing we can do about that since there's no way to pass a 'state' object into ContinueWith in .NET 4. Since we moved the TCS into closure, now the ContinueWith call ends up returning a Task<Task<TOut>>, so we use the Unwrap extension method, whose job is to shed that outer Task.

Unobserved Faulted Tasks

I started this blog post talking about the bug with unobserved faulted tasks, but... I didn't actually fix that problem. We still need to be sure to observe innerTask.Result so that any faulted task can re-throw its exception appropriately, and we won't end up with a task whose errors weren't observed bringing down our AppDomain. In addition, it seems silly for us to throw exceptions by observing a faulted task just so that it can be turned back into another faulted task, so we'll see if we can deal with that, too.

In the next post in the series, I'll talk about splitting out this one helper method into several optimized methods for each specific scenario (successful results, faulted results, and cancelation), which will also cure of us needing to observe properties on the Task object just to ensure we don't crash later.

1. Introduction
2. SynchronizationContext
3. ContinueWith
4. TaskHelpers

Introduction to SynchronizationContext

An important part of the work in properly handling tasks on the server is supporting the synchronization context. When you’re using .NET 4.5, then the await keyword automatically does this for you. When you’re consuming Task objects on .NET 4, though, getting yourself back onto the right synchronization context is critical; otherwise, you may cause errors in your application when trying to access things which touch the HttpContext in ASP.NET.

If you’re using ContinueWith to provide a continuation to run when the task is finished, then you’ll want to stash the SynchronizationContext and restore when it’s not null. The way you get back onto the right sync context is by calling Post, which is itself an async method…but it’s an async method that returns void, not a Task. The problem is, we’re going to want to return a task that doesn’t finish until everything is done running in the Post callback. How can we do that without a Task?

To be clear, there is nothing Task-specific about sync contexts. They've been with us since .NET 2.0, and if you ever did async/threaded work in ASP.NET (or anything else which has a sync context, like WinForms or WPF), you've always had to respect it. This is one the great things about await in .NET 4.5: it means you can more or less just forget about this, because the compiler is writing all the boilerplate code that I'm about to show you.

TaskCompletionSource: Bridging non-Task async to Tasks

The TaskCompletionSource class is an interesting beast. It’s an implementation of the task pattern whose task doesn’t mark itself as signaled until you call one of the methods that records whether the task is completed successfully, failed from an exception, or canceled.

As an example of how this works, let’s say you’re calling an "old school" .NET async API that uses the Async/Completed pattern (meaning, it uses events to signal when things are done), and you needed to convert this into a task. Your method might look like this:

public Task<int> SuperAccurateButSlowAdd(int x, int y)
{
    asyncCalculator.Completed += (src, evt) =>
    {
        int result = evt.Result;
        // But now what do I do with it?
    };

    asyncCalculator.AddAsync(x, y);
    // And what do I return here?
}

The solution to both of the problems above is to use TaskCompletionSource.

public Task<int> SuperAccurateButSlowAdd(int x, int y)
{
    var tcs = new TaskCompletionSource<int>();

    asyncCalculator.Completed += (src, evt) =>
    {
        int result = evt.Result;
        tcs.SetResult(result);
    };

    asyncCalculator.AddAsync(x, y);
    return tcs.Task;
}

One of the contracts for methods which return Task or Task<T> is that they should only throw exceptions if there was a problem with one of the parameters; otherwise, if they encounter an error in normal execution flow, then they should return a faulted task. So with error handling in both places that could throw, now our code looks like this:

public Task<int> SuperAccurateButSlowAdd(int x, int y)
{
    var tcs = new TaskCompletionSource<int>();

    try
    {
        asyncCalculator.Completed += (src, evt) =>
        {
            try
            {
                int result = evt.Result;
                tcs.TrySetResult(result);
            }
            catch(Exception ex)
            {
                tcs.TrySetException(ex);
            }
        };

        asyncCalculator.AddAsync(x, y);
    }
    catch (Exception ex)
    {
        tcs.TrySetException(ex);
    }

    return tcs.Task;
}

Since you asked, yes, we do need both of those try/catch blocks. Although it's not clear at first glance, there are actually two functions in here: the main body of SuperAccurateButSlowAdd, and the lambda (anonymous function) that we've wired up to the Completed event. Of course, if you know neither one of those things can throw, then you can remove the try/catch, but you better be positive, because in some cases you could end up in a permanent waiting state.

If you're thinking this code is ripe for "helper methods", you're right. You're going to see that our Task helper methods are really about reducing the code duplication to a single place, and wrapping things up with nice unit tests to boot.

Using TaskCompletionSource so we can call SynchronizationContext.Post

Now that we know how to adapt something which isn't Task into something which is, this is what our code looks like when we want to do a ContinueWith and get back on the proper sync context:

var ctxt = SynchronizationContext.Current;

return SomeThingReturningATask()
      .ContinueWith(innerTask =>
{
    var tcs = new TaskCompletionSource<int>();

    try
    {
        if (ctxt != null)
        {
            ctxt.Post(state =>
            {
                try
                {
                    int result = innerTask.Result;
                    tcs.TrySetResult(result);
                }
                catch(Exception ex)
                {
                    tcs.TrySetException(ex);
                }
            }, state: null);
        }
        else
        {
            int result = innerTask.Result;
            tcs.TrySetResult(result);
        }
    }
    catch(Exception ex)
    {
        tcs.TrySetException(ex);
    }

    return tcs.Task;
});

Wow, look at all that duplication! :( And it's getting pretty hard to see our code for the noise. We're definitely going to want a helper here. And what's worse is that our code has a bug, and now it's hard to see what it is.

The next blog post will talk about what that missing code might be.

1. Introduction
2. SynchronizationContext
3. ContinueWith
4. TaskHelpers

Okay, let’s just get this out of the way:

Asynchronous (multi-threaded) programming is not easy.

This warning really has nothing to do with .NET in particular, because it can be quite challenging to do correctly on any framework, but here’s the good news:

Asynchronous programming with .NET 4 is a little easier.
Asynchronous programming with .NET 4.5 is a lot easier.

The Task Parallel Library (or, as we think about it, Task and Task<T>) were introduced in .NET 4. This library dramatically simplified the more complex async patterns from previous versions of .NET (which includes the begin/end pattern as well as the async/completed event pattern).

The async and await keywords available in C# and VB on .NET 4.5 mean you get to consume Task Parallel Library tasks with code that looks linear and synchronous, but is in actuality asynchronous, with none of the callback handlers or thread synchronization stuff getting in the way. For most developers, this means that asynchrony is simple enough to consume without too much trouble; in fact, the Windows team is so confident of this that all the APIs for modern apps in Windows 8 that might “take a while” (read: more than 100ms) are required to be async, with no synchronous counterpart. The Windows team did this so that you won’t inadvertently lock up the UI and cause the app to appear to be unresponsive, although of course you could end up doing this by running some long running process in your own code on the UI thread.

As such, a great deal of the samples for 4.5 using Task<T> are centered around pushing “long running” tasks onto a background thread so you don’t lock up the UI. There are also a decent number of samples that show using the TPL for parallel processing: that is, when you have something which is CPU-bound, and can be split up into discrete tasks, you run many of them in parallel so as to get the best use of modern multi-core CPUs.

There is another category of asynchronous programming, though, that has had very little ink devoted to it: server-side programming; in particular, using Task<T> when writing web applications and web APIs, which yields the real purpose for this blog post:

Asynchronous programming for servers is not the same as clients.

Client asynchrony is all about getting work off the all-important UI thread, so that the UI appears to be response to the user, even when working is going on in the background. On a server, there is no such thing as a background thread vs. a UI thread: every thread in the thread pool is a potential handler for a request, and the client has to wait until all the work is done, regardless of which thread(s) it takes place on.

In the context of servers, the most important thing to remember is that we don’t want to switch threads if at all possible, because a thread context switch can dramatically reduce the scalability of your server. That means whenever you consume a task, you have to be careful to use mechanisms that don’t switch the thread unnecessarily.

In addition, there’s no point in making a task on the server when what you’re doing is fundamentally CPU-bound. There’s no background thread for this work to hide on, so all you’re doing is incurring an expensive thread switch. Where TPL makes sense on servers is when you’re consuming something which is fundamentally async but not CPU bound, which means things like database operations and web service calls.

A final consideration for your server-based TPL code is synchronization contexts. The SynchronizationContext class was introduced in .NET 2.0 as an abstraction around the need for asynchronous code to get its state lined back up to continue correctly functioning. In the case of Windows Forms and WPF, this means ensuring that your post-async code is running on the UI thread so that you can do UI manipulation; in the case of ASP.NET, this means ensuring that your current thread has all the necessary thread-local statics set up (so that calls like HttpContext.Current function correctly).

Further blog posts in this series will talk about how to safely consume Tasks from your server code on .NET 4, and some rather in-depth analysis of the task helper libraries that the ASP.NET team has made to ensure that Task-related code runs in the way that incurs the least amount of performance impact.

http://xunit.codeplex.com/discussions/351482

Update #1: Samsung has released Windows 8 drivers to support better touch and rotation with Windows 8. Please go download them now!

Update #2: There is a forum post outlining how to get WiDi (wireless display) working in Windows 8. Since I don't have a WiDi endpoint and thus can't test this, I can't really speak to the  effectiveness of the instructions.

This is an update to my previous post about running Windows 8 Developer Preview on the Samsung Series 7 Slate. Until we get Windows 8 logo'd hardware, I believe this to be the best developer device for doing early explorations into Windows 8 development on.

That said, this is still beta-level software. Tread carefully. :)

Obligatory Warning You Will Probably Ignore

What you're doing here is erasing a computer. You can screw things up if you do them incorrectly. This worked for me, but it may not work for you. If you get stuck, I may not be able to help you, and Samsung may not be super excited about helping you out with a Windows 8 problem. Also, Windows 8 is pre-release software, so expect some occasional bumps in the road.

Although you can upgrade your existing Windows 7 partition to Windows 8, I'm a big proponent of the "clean slate" mentality, so this blog post was written with that in mind. If you're insistent on doing an upgrade instead, please remember to do the pre-installation steps (0 and 1), because they apply whether you're paving or clean installing. Then in step 2, instead of booting the USB device, just insert it into the USB slot while booted into Windows 7 and it should offer to run setup and do the upgrade for you.

Important Links:

• Windows 8 Consumer Preview Download
• Making a bootable USB thumb drive from the Windows 8 ISO
• Samsung Series 7 Slate Software Downloads
• Samsung Series 7 Slate drivers for Windows 8

What You'll Need to Get Started

• A bootable USB device to install Windows 8; meaning, either a USB DVD drive or a USB thumb drive. If you want to use the latter, follow the instructions linked above to make the thumb drive properly bootable. You'll want a 4GB+ thumb drive for Windows 8 x64. Your machine has 4GB of RAM, so don't bother with the x86 (32-bit) verison of Windows 8. Installation from a USB thumb drive is a LOT faster than installation from a DVD (and doesn't waste a blank DVD).
   
  Pro-Tip: format the USB device as FAT32, not NTFS, if you want to enable UEFI boot (which should speed up your already quite fast booting process on this device). When booting, if offered two different versions of your USB boot device, choose the one with "EFI" in its title.
   
• A keyboard and mouse is highly advised for some parts. You can get by without it, but it's... painful. If you're planning to use a USB keyboard, bear in mind that you'll be booting off of a USB drive, so you'll either need a USB hub, or you'll need to use the optional dock to get yourself a 2nd USB port.

Step 0: Update your firmware (before you delete Windows 7!)

Your machine may have shipped with the latest firmware, but it's worth verifying that to be sure. A relatively new firmware (version 08FW at the time of this writing) is necessary to ensure that TPM and Bitlocker work correctly, and will also be necessary for screen rotation support when the driver becomes available.

Boot into Windows 7. Visit the Series 7 Slate Downloads page, click on the Manuals & Downloads tab, then the Firmware link, and download the firmware updater. Run it to ensure you are on the latest firmware.

Note for advanced users: I created a "boot from VHD" version of Windows 7 for updating my firmware. It "costs" me about 20GB of my drive, which is kinda steep, but it's worth it to have something that allows me to upgrade my firmware whenever there's a new version. Besides Windows 7, all I've installed is the Samsung drivers/software necessary to update the firmware. Once the Samsung tools become fully Windows 8 compatible, then I'll be able to reclaim this. If you need help understanding how to do this, Scott Hanselman's Guide to Installing and Booting Windows 8 Developer Preview off a VHD illustrates the steps excellently, which work for both Windows 7 and Windows 8.

Step 1: Make some machine settings changes

With the machine in a powered off state, press the POWER button, then quickly tap (but do not hold) the HOME button. Now be patient, you should see the boot menu (of which one option is to boot into the firmware). Don't get anxious and hit it a second time, because you're almost sure to accidentally escape out of the boot menu; trust me, I think I did this 3x before I learned to be a tiny bit more patient. :)

The contents of this menu will vary depending on which boot features you've enabled; for me, they were:

P0: SAMSUNG MZMPA128HMFU-00000 (this is your SSD drive)
SMI USB DISK 1100 (this is my 8GB USB stick that I'm planning to boot from)
Realtek PXE B02 D00 (this is the network boot via Ethernet)
Enter Setup (this will drop you into the machine settings again) 

Attaching a USB keyboard helps navigation here a lot (though you should attach it before you power on the device; I don't think it will detect it if you try to plug it in later). If you don't, then you'll need to use the hardware keys to navigate:

• Rotation Lock (on the right, below the power button)- Enter
• Home (the only button on the face of the device) - Escape
• Volume Up/Down (on the left, below the USB port) - Move the cursor up/down
• Hold Rotation Lock + Volume Up/Down - Move the cursor left/right

Use the USB keyboard (or the volume up/down keys on the device) to select "Enter Setup", then press Enter (or Rotation Lock on the device). Once in the firmware, the machine settings screen is displayed:

The BIOS changes we want to make/verify are all on the Advanced page:

• CPU Power Saving Mode : Enabled
• Hyperthreading : Enabled
• Execute Disable Bit : Enabled
• Legacy USB Support : Enabled
• UEFI Boot Support : Enabled

There are two additional interesting settings on the Boot page, which you may or may not want to change:

• TPM Support : you'll want to Enable this if you want to use Bitlocker to secure the contents of your slate. Some corporate environments (like mine) require that you use Bitlocker, and TPM means you won't have to carry around an extra USB key with Bitlocker booting codes on it.
• PXE OPROM : you'll want to Enable this if you have the optional dock, and you're planning to install Windows via the network, as network booting requires a physical Ethernet connection. This is probably not useful right now with Windows 8, but you may find it useful if you decide to revert back to Windows 7 at some point (assuming you're on a network with network boot support).

Navigate to the Exit page, and choose "Save Changes and Reset". But before you do that, read ahead just one more paragraph.

Step 2: Boot the USB device to install Windows 8

When the machine reboots after we save and exit the settings screen, once again we want to tap and release the HOME button once to get to the boot menu. This time, navigate to the USB device that you're booting from and select it. (Remember, if you're not using a USB keyboard, you can use the device keys Volume Up and Volume Down to move, and Rotation Lock to select.)

The Windows 8 installation includes enough drivers to do mouse emulation for the slate's touch screen, so I was able to touch my way through the install process. I nuked both the Windows 7 partition and the factory restore partition, because I was confident that I would rather reinstall Windows 7 from scratch anyway. Just bear in mind that your slate didn't come with a Windows 7 DVD (or thumb drive), so unless you have an extra Windows 7 DVD hanging around that's usable for this, you'll want to preserve the factory restore partition. Me, I wanted that extra 20GB back. :)

Since there is no on-screen keyboard, if you want to do any advanced partitioning, you'll basically have to boot with a USB keyboard connected for the installation. Tapping the down arrow on the partition size edit box over and over again gets old REALLY fast. :)

After you've picked your installation partition, the system will do its copy thing and then reboot to finalize the installation. Now Windows 8 is running in full swing, and final settings (like connecting to WiFi and logging in with your Windows Live ID) are touch-friendly operations with on-screen keyboards available.

After your initial logon, you're on the Start Screen. At this point, I'd recommend connecting your Bluetooth keyboard and mouse (if you're using USB, then there's no connection necessary other than just plugging things in). FWIW, the Start Screen is great on this slate, but classic desktop mode can be challenging without a keyboard and mouse. I wouldn't recommend it for anything other than casual usage, and instead limit yourself to the Start Screen (and touch-designed apps) when you don't have a keyboard and mouse.

Alternatively, you can use the provided pen for light mouse-like usage. This slate comes with both a real digitizer as well as touch screen, and it turns off the touch functionality when the pen is nearby, so it's actually quite nice to write with using the provided pen, as you can lean the edge of your hand on the glass to write without triggering any touch operations. Honestly, this is a great slate for people who like to write, and I suspect I'll get a lot more use out of OneNote with this than any previous PC.

Regardless of what kind of precision input device you're using, we're going to make some changes and do some work in classic desktop mode next.

Step 3: Run Windows Update

From the Start Screen, swipe in from the right edge, tap Search, and then search for "Windows Update". Tap on the Settings sub-search, and then tap on "Check for updates". This will launch the desktop version of Windows Update. If you're careful with your taps, you might be able to use this app without resorting to a mouse or pen.

Force Windows Update to search for drivers, even if it thinks you're up-to-date. This will end up giving you most of the drivers you're missing. For me, this included nearly 20 updates in total. As is typical with Windows Update, you will probably need to reboot one or more times to get everything updated properly. Continue to install/reboot dance until Windows Update comes up empty.

Step 4: Install Drivers For Missing Devices

When you look in Device Manager, you'll probably have two "banged out" devices that are missing drivers. One is the rotation sensor (for which there aren't any drivers yet), and the other is a device that's covered in the Intel Chipset drivers.

Head back to the Series 7 Slate Downloads page. Click on the Manuals & Downloads tab, but this time click on the Driver link, and download the driver named "Chipset". Install this driver and reboot. One of your two mysteryous devices with no driver should have gone away now.

Update: Samsung has released Windows 8 drivers to support better touch and rotation with Windows 8. Please go download them now!

Step 5: There is No Step 5

That's it! The Consumer Preview version of Windows 8 just continues to make my blissfully happy with my investment in this "developer-quality laptop without a keyboard". It really shines!

Time to enjoy your new Windows 8 slate!

There are a few big new features that are worth calling out.

Async Unit Tests

Late in 2010, the C# team announced a new feature that was coming in C# 5: the "async" and "await" keywords. These keywords allow the developer to consume Task-based asynchronous APIs with code that looks linear and procedural, and mimics the code that the developer would write when calling synchronous APIs. In addition, .NET 4.5 is introducing new Task-based async APIs to supplement the existing event-based asynchronous APIs, and new async APIs will only offer Task-based versions.

Before now, unit testing these asynchronous APIs meant resorting to calls like .Wait() and .ContinueWith(), since unit testing frameworks are inherently synchronous by nature. With the release of 1.9, xUnit.net allows you to write asynchronous unit tests by marking your test method with the "async" keyword, and changing the return value from void to Task.

Prior to 1.9, a unit test around an asynchronous API might look something like this:

[Fact]
public void MyAsyncUnitTest()
{
    // ... setup code here ...

    Task task = CallMyAsyncApi(...)
               .ContinueWith(innerTask =>
    {
        var result = innerTask.Result;

        // ... assertions here ...
    }

    task.Wait();
}

The code gets sufficiently more complex with every additional asynchronous API you add into the mix (for example, calling some async APIs during the setup phase of the unit tests). Adding try/catch logic becomes difficult and/or redundant, as the exception handling logic needs to be duplicated for both the setup code and the ContinueWith handler).

The same unit test can be simplified by using xUnit.net 1.9 (and either the Async CTP, or the pre-release version of .NET 4.5 which includes C# 5):

[Fact]
public async Task MyAsyncUnitTest()
{
    // ... setup code here ...

    var result = await CallMyAsyncApi(...);

    // ... assertions here ...
}

xUnit.net does the rest of the work. It sees that you're returning a Task and waits for it to complete. Traditional sequential coding mechanics like try/catch/finally and using are much easier to reason about when using async/await, and the compiler takes care of the boilerplate code necessary to ensure that it all works properly.

Generic Theories

One of the most used features in the xUnit.net Extensions project is support for theories. In quick review: Facts are for expressing tests which are invariants; Theories are used for expressing tests that are only necessarily true for a given set of input data. As such, theories are sometimes called "data-driven unit tests", because part of testing a theory is providing sets of conforming data.

The new Generic Theories feature allows the developer to write their theories using the .NET generic method syntax. xUnit.net will attempt to determine the best signature for the generic types of the method based on the provided data, and it makes this decision individually on a data-row by data-row basis. This is most useful for writing unit tests against generic APIs, wherein you want to choose the generic API to call based on the type of the input data.

For example, here is a unit test which is testing a generic get-and-cast behavior of a container:

[Theory]
[InlineData(42)]
[InlineData(21.12)]
[InlineData("Hello, world!")]
public void CastingGetTest<T>(T value)
{
    MyContainer container = new MyContainer();
    container.SetValue("name", value);

    T result = container.Get<T>("name");

    Assert.Equal(value, result);
}

This generic theory will be called 3 times as expected, and the type of T will be implied based on the value that was provided. We've also updated the output from theories to include any generic types that were used, so if this theory fails, its output method names would be:

CastingGetTest<Int32>(value: 42)
CastingGetTest<Double>(value: 21.12)
CastingGetTest<String>(value: "Hello, world!")

This highlights another new feature of 1.9 as well: theory names include parameter names in addition to parameter values.

The rules for matching are fairly straightforward:

• If the generic type has no matching parameters, we use Object
• If the generic type has one matching parameter:
• If the parameter value is non-null, we use value's concrete type
• If the parameter value is null, we use Object
• If the generic type has two or more matching parameters:
• If the parameters are the exact same concrete type, we use the concrete type (note that a null value is type-compatible with any reference type, but type-incompatible with any value type)
• If the parameters are not the exact same concrete type, we use Object

We could've gone with a more complex matching algorithm, but we wanted the results to be easy to understand and reasonably predictable without stashing away dozens of matching rules in your head.

An important note: this support is limited to generic test methods only. xUnit.net does not support generic test classes.

I flirted with buying my music only online this year, but have since switched back to CDs, so that I can rip everything in lossless. Automatic downconversion to the phone is great, and I can still keep my lossless audio streams for the house, and all it costs is disk space (for my complete music collection, that's roughly 1TB). This is also the year I dumped my Zune Pass, and tried (but failed to be captivated by) Spotify.

Previous years: 2010, 2009, 2008, 2007

Genre: Alternative

R.E.M. — Collapse into Now

2011 is the year that R.E.M. released its first truly great album in probably a decade... and then promptly broke up. Good jorb, guys.

Genre: Metal

Anthrax — Worship Music

Against all odds, Anthrax is back, and with Joey back at lead vocals. Worship Music is a great throwback to the classic 'thrax of olden days.

Iced Earth — Dystopia

I had more or less written off Iced Earth as being uninteresting. There was the flirtation with Tim "Ripper" Owens that yielded one great album and a bunch of meh. Then they went back to long-time singer Matt Barlow, but he didn't seem to have the heart, and was gone after one album. Now they've found another (their 5th?) in Stu Block, and his vocal style honestly combines the best of Barlow and Ripper, and the music feels emotionally inspired again. Welcome back, guys!

Mastodon — The Hunter

Mastodon's last album was a mixed bag: some thought it was the best of their career, and some thought it the worst. I definitely found myself in the former camp, and I think The Czar remains some of the best stuff they've ever done. This new album is quite good, though not quite up to the standards of the last album. It feels less progressive and more conventional.

Megadeth — Th1rt3en

Megadeth have always been a more consistent band than Metallica for metal fans (Risk notwithstanding), and their 13th studio album still delivers the fire from the old days.

Symphony X — Iconoclast

A new SymX disc is always cause for celebration. Russell Allen has one of the greatest voices in metal (now that Dio is no longer with us), and their symphonic/power metal prowess is, as always, honed to a very fine edge.

Within Temptation — The Unforgiven

I'm a sucker for concept albums and for female metal singers, so this was a double dose for me. It's a little pop-ish for some metal fans' tastes, but Sharon den Andel is always great to listen, because she tends to have a more reserved style than many other female metal singers. The bonus videos with the album were an excellent treat!

Genre: Extreme Metal

Amon Amarth — Surtur Rising

I'm a latecomer to Amon Amarth (and extreme metal in general), so while others didn't really think much of Twilight of the Thunder Gods, I liked it quite a lot. Surtur Rising is superior in pretty much every important way, and is a regular player even many months after its release.

Arch Enemy — Khaos Legions

Another refinement in the melodic death metal machinery of Arch Enemy... yes, it's different than the old material, but it's pretty great in its own right.

Between the Buried and Me — The Parallax: Hypersleep Dialogues

Calling this "just a three song EP" downplays the masterful music that spans nearly 30 minutes, almost long enough to be considered an album were this 20 years ago. Just whets the appetite for the next full length album...

The Black Dahlia Murder — Ritual

There isn't a lot of metal coming out of my home town of Detroit these days, but TBDM more than make up for it with some seriously brutal yet brilliantly melodic metal.

Fleshgod Apocalypse — Agony

I'd never heard of these guys before hanging out on Turntable.fm, so imagine my surprise at the unbelievable combination of technical death metal and orchestral arrangements that awaited me. The talent in this band, especially the drummer, is nearly inhuman.

Ghost Brigade — Until Fear No Longer Defines Us

Listening to this album Every. Single. Day. 'nuff said.

Insomnium — One for Sorrow

Insomnium are yet another one of those quiet, competent ass-kicking melodic death metal bands that doesn't ever quite get the recognition it deserves. Another fine outing!

Obscura — Omnivium

Ever since Metallica started opening their albums with acoustic, classical-inspired snippets, I've had a fondness for the unexpected during those first 60 seconds of the album. Obscura bat it out of the park with this opener!

Omnium Gatherum — New World Shadows

This is my first album from the Finnish melodic death metal band, but it definitely won't be my last. Soul Journey is probably one of the best melodeath songs of the year.

Opeth — Heritage

Mikael disappointed a lot of long-time fans when he announced that Opeth's newest album would not only be all clean vocals, but a rather stark musical departure at that. More inspired by 70's fusion jazz and progressive rock than modern metal, it really hits a sweet spot for me. The whole album is audible candy.

Scar Symmetry — The Unseen Empire

When Christian left Scar Symmetry, many fans were shocked that they replaced him with not one but two vocalists. Although both can sing and growl, each has their stronger suits. The resulting first album was Dark Matter Dimensions, and most long-time fans thought it was probably the end of old SS. The Unseen Empire proved that they just need to get back on creative track.

Genre: Progressive Rock/Metal

Andromeda — Manifest Tyranny

I've always been a pretty big fan of Andromeda's mix of prog metal and futuristic sounds and topics. This new album definitely steps up the pace quite a bit at times, especially the opening track.

Arch/Matheos — Sympathetic Resonance

This is probably metal heresy, but there's something very Queensryche-ian about Arch/Matheos, which is to say that it reminds of the glimpse of the greatness that Operation: Mindcrime convinced us Queensryche had inside, but couldn't quite deliver on reliably. Arch/Matheos have no such problems.

Dream Theater — A Dramatic Turn of Events

With no small amount of irony did Dream Theater choose the name of their latest album. This year saw the band lose one of its founding members (and musical backbone) in Mike Portnoy. DT decided to keep moving forward and hired Mike Mangini, and turned the audition and hiring process into a three part YouTube series. Just as importantly, they created some of the most solid material in more than a decade.

Evergrey — Glorious Collision

Evergrey are like the Little Prog Metal Band That Could. They keep soldiering on in undeserved obscurity, turning out album after album of incredibly solid music.

Protest the Hero — Scurrilous

This is PtH's most commercially acceptable release, which is still a long damn way from what other bands might call "selling out". The undertone of crazy is still here, though.

Steven Wilson — Grace for Drowning

Steven Wilson is the brains behind Porcupine Tree, and a long-time musical collaborator with Mikael and the boys in Opeth. His solo work tends to be more experimental and atmospheric than Porcupine Tree.

TesseracT — One

One of the most refined and unique sounds in progressive metal today, TesseracT were an obvious immediate addiction to me.

Textures — Dualism

Textures blends a bit of progressive metal, and occasional metalcore and djent tendencies.

Genre: Soundtrack

The Girl With the Dragon Tattoo

Trent Reznor seems to have diverted his career into soundtracks, and with great success. Last year his big success was The Social Network; this year, he succeeds well with The Girl With the Dragon Tattoo. The opening credits have this quite good cover of Led Zeppelin serving as the audio backdrop.

Tron: Legacy Reconfigured

Technically, the original soundtrack came out last year with the movie, but there was a remix CD released this year. The most shocking thing about it is how much better it is than the original, which I would've said was one of the best soundtracks released in many years.

DISCLAIMER: You're about to mess with registry settings and network settings. You could seriously break things if you do it wrong, and there's no guarantee I've done everything right. Make sure you have a backup before doing anything like this.

For the most part, the network just works. The VM gets an IP address from Hyper-V on the private network, and it's able to get out to the public network transparently. The one problem is that the resulting network bridge is labeled as a "public" network. This means that the host could ping the VM, but the VM couldn't ping the host. Since Windows doesn't see any Internet path on the shared network, it marks it public without any option for making it private:

The key is to trick Windows into thinking that the network is a point-to-point network instead of a traditional Ethernet network, so that it will always be considered a private network. To do this, open REGEDIT and navigate to the section of the registry that contains the network drivers:

HKEY_LOCAL_MACHINE\
    System\
        Current Control Set\
            Control\
                Class\
                    {4d36e972-e325-11ce-bfc1-08002be10318}

Inside this key, you'll find a couple dozen keys for various network adapters. You're looking for the key(s) whose DriverDesc value is "Microsoft Virtual Switch Network Adapter". When you find that key, you need to add a new DWORD value named "*NdisDeviceType" with a value of "1", as illustrated below:

Once you've done this, then reboot the host PC. Once you've rebooted, the network device will not show up in the Network and Sharing Center any more, since point to point network devices don't show in that list. Now the VM will have a private network with the host, so it will be able to access anything that the host normally permits to go through the private section of the firewall.