Brad Wilson

Task Parallel Library and Servers, Part 4: TaskHelpers

This is part 4 in a series on using Task Parallel Library when writing server applications, especially ASP.NET MVC and ASP.NET Web API applications.

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.

Task Parallel Library and Servers, Part 3: ContinueWith

This is part 3 in a series on using Task Parallel Library when writing server applications, especially ASP.NET MVC and ASP.NET Web API applications.

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.

Task Parallel Library and Servers, Part 2: SynchronizationContext

This is part 2 in a series on using Task Parallel Library when writing server applications, especially ASP.NET MVC and ASP.NET Web API applications.

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.

Task Parallel Library and Servers, Part 1: Introduction

This is part 1 in a series on using Task Parallel Library when writing server applications, especially ASP.NET MVC and ASP.NET Web API applications.

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.

Making Hyper-V Internal Network Private

Today, I installed Hyper-V on my Windows 8 machine so I could make a VM for a demo I'm giving later this week. I set up the virtual network as an internal network, and then used Windows 8's internal bridging system to bridge the internal network over to the live WiFi.

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.

The "Testable Object" Pattern

This is a republished blog post from 2007. You can tell it's old because the tests were in NUnit instead of xUnit.net. :)

I've demonstrated this a few times in presentations, and someone will inevitably ask for more information. Truth is, I don't remember when I came up with it, or where I might've been inspired for it. I should say up front that I don't believe in mock object frameworks (because they encourage white-box protocols), and I don't believe in [SetUp] and [TearDown] (because they hide intention and force the use of fields in test fixtures, which should be strongly discouraged).

get-isadmin.ps1

Here's a simple way to tell if you're running as an administrator from within PowerShell:

$windowsIdentity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$windowsPrincipal = new-object 'System.Security.Principal.WindowsPrincipal' $windowsIdentity

return $windowsPrincipal.IsInRole("Administrators")

I like to use this right at the top of my startup profile to turn my window background dark red:

if ((get-isadmin) -and (-not $psISE)) {
    $Host.UI.RawUI.BackgroundColor = "DarkRed"
    clear
}

Since the raw UI can only use colors from the console, I also tweak my console's interpretation of dark red into (48,0,0) so that it's very dark, nearly black but still recognizably red. I also change my prompt color from green to yellow. It's very obvious looking at green on black vs. yellow on red that I'm in an admin prompt.

I check to make sure we're not running in the ISE, because the ISE runs a dark on light color scheme and doesn't paint the same way as the console version of PowerShell.

Selecting CLR Version From Unmanaged Host

I just saw this go by on an internal DL and it seemed worth documenting.

What is the correct way determine what framework version is installed on a computer to choose the correct CLR hosting approach?

I would like to use CLR 4.0 runtime if CLR 4.0 is installed (and use CLRCreateInstance -> ICLRMetaHost->GetRuntime), but if it is not installed, I’d use CorBindToRuntimeEx.

According to MDSN, GetCORVersion is deprecated. What should I use instead? ICLRRuntimeInfo::EnumerateInstalledRuntimes would not work in an environment where CLR 4.0 is not installed, correct?

I would like my code to work in CLR 2.0+ environment.

And the answer:

• LoadLibrary mscoree
• GetProcAddress for CLRCreateInstance. If you get NULL, fall back to legacy path (CorBindToRuntimeEx)
• Call CLRCreateInstance to get ICLRMetaHost. If you get E_NOTIMPL, fall back to legacy path (same as above)
• Otherwise, party on the ICLRMetaHost you just got

Calculating SHA1 in PowerShell

I can never remember where (or the name of) the random .EXE that I usually keep around for calculating SHA1 hashes is, and it seemed silly not to just spend the 10 minutes to write it in PowerShell. After all, everything you need is in .NET, right?

param([switch]$csv, [switch]$recurse)

[Reflection.Assembly]::LoadWithPartialName("System.Security") | out-null
$sha1 = new-Object System.Security.Cryptography.SHA1Managed
$pathLength = (get-location).Path.Length + 1

$args | %{
    if ($recurse) {
        $files = get-childitem -recurse -include $_
    }
    else {
        $files = get-childitem -include $_
    }

    if ($files.Count -gt 0) {
        $files | %{
            $filename = $_.FullName
            $filenameDisplay = $filename.Substring($pathLength)
            
            if ($csv) {
                write-host -NoNewLine ($filenameDisplay + ",")
            } else {
                write-host $filenameDisplay
            }

            $file = [System.IO.File]::Open($filename, "open", "read")
            $sha1.ComputeHash($file) | %{
                write-host -NoNewLine $_.ToString("x2")
            }
            $file.Dispose()

            write-host
            if ($csv -eq $false) {
                write-host
            }
        }
    }
}

pause.ps1

I needed a "pause" command for some of my PowerShell scripts, so this is what I ended up with. Enjoy.

param(
  [string]$message = "Press any key to continue..."
)

Write-Host -NoNewLine $Message

$Host.UI.RawUI.FlushInputBuffer()
do { $key = $Host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown").Character } while ([int]$key -eq 0)

Write-Host ""