First, is an abstraction around the User Interface thread, IUserInterfaceContext. This exists today in the form of SynchronizationContext, but I favor this specific interface because

1. It’s more explicit (the SynchronizationContext applies to more than just the main UI thread) whereas this is very clear what its purpose is.
2. The API is cleaner – passing a “state” is unnecessary with nested closures.
3. It’s easier to grab out of an IoC container. Because a SynchronizationContext is only specific to the context it was created in (which could be a background thread) it’s not meaningful to put a SynchronizationContext argument in your constructor. Which one do you want?

public interface IUserInterfaceContext
{
    void Execute(Action action);
    void ExecuteAndBlock(Action action);
}

Now, any component in my application can execute code on the UI thread extremely easily. I just register the implementation of IUserInterfaceContext (which does use a SynchronizationContext) when my application is started, which is on the UI thread.

The implementation could look something like this:

public class UserInterfaceContext : IUserInterfaceContext
{
    private readonly SynchronizationContext _syncContext;

    public UserInterfaceContext(SynchronizationContext syncContext)
    {

        /* Ensure the SynchronizationContext passed in is the main UI thread context */
        _syncContext = syncContext;
    }

    public void ExecuteAndBlock(Action action)
    {
        if (_syncContext != null)
        {
            _syncContext.Send(s => action(), null);
        }
        else
        {
            action();
        }
    }

    /// <inheritdoc />
    public void Execute(Action action)
    {
        if (_syncContext != null)
        {
            _syncContext.Post(s => action(), null);
        }
        else
        {
            ThreadPool.QueueUserWorkItem(s => action(), null);
        }
    }
}

Secondly, is a more generalized example of Jeremy Miller’s ICommandExecutor, which is even more generalized as the Active Object pattern. I named mine “IAsyncExecutor” because it executes any code asynchronously. The advantage with this approach is that it drastically simplifies test activities to be able abstract multithreading (to a point) and allow a test to run single threaded. That is nothing but pure win. We’ve also found that using the interface makes the code read better than using a bunch of BeginInvoke/EndInvoke’s or the ThreadPool, or an async pattern such as “void FooAsync(AsyncCallback callback, object state);

public interface IAsyncExecutor
{
    void Execute(Action action);
    void Execute(Action action, Action after, bool callbacksOnUIThread);
    void Execute(Action action, Action after, Action<Exception> error, bool callbacksOnUIThread);
}

You’ll notice that IAsyncExecutor looks a lot like IUserInterfaceContext, and in fact, it can use it under the covers if the callbacksOnUIThread is true.

Both of these are simple interfaces, with trivial implementations, but you’d be surprised how often I’ve wished I’ve had them in the past. What are some “core” interfaces/services/etc that you *must have* in your toolbox?

• Let me inject core application services (or higher level aggregated services, or ANYTHING I WANT) by pulling them out of my IoC container
• Not require the service to run in a new AppDomain
• Be easy to use, configure, and integrate into my application
• Be testable

I’m going down the path of exposing a Web API (I would call it a RESTful service, but really it’s not). Of course my first stop was to investigate hosting ASP.NET MVC in a desktop application (which really just means hosing ASP.NET). There are a few articles out there about how to do this, and for the “intended” scenario, it’s pretty easy.

Unfortunately the “intended” scenario is web hosting, which loads everything into a new AppDomain. And aside from some of the outer classes and factories, everything is marked private or internal so I can’t get at it without doing a bunch of reflection. Bah.

I’ve ended up taking a long look at OpenRasta. OpenRasta was written with DI/IoC in mind, and it actually uses an internal IoC container for configuring the framework. More on that in a future post. It also has it’s own hosting support and API that have out-of-the-box implementations for ASP.NET, HttpListener, and “In Memory”. But you could always implement your own hosting code and integrate it.

The key word in that entire paragraph was “HttpListener”. That’s built-in .NET support for for web request processing that is baked into Windows via the kernel-mode http.sys driver. It’s relatively easy to use, and it’s wonderful. OpenRasta integrates with my existing application infrastructure, and marries it up with support for a REST-style web API, enabling me to very quickly expose a web API that allows third parties to integrate with my application. This is going to be more and more important as things like Windows Gadgets are implemented which are restricted in terms of the kinds of ways they can communicate (web requests) and with whom they can communicate (localhost, etc.)

Unfortunately OpenRasta doesn’t support Ninject, which I use, so I’m implementing the support for it and will submit the patch soon.

So far I’m extremely happy with the solution as I think developer productivity will be through the roof (compared to other more invasive solutions like WCF) and client-side integrations won’t be that difficult (POX). For my scenario, it’s all right up my alley. The internetz work for ME now!

One such not-so-subtle bug (application hang) is particularly nasty, and is described fairly well here. Distilled down, the application hangs, usually when the computer comes out of sleep mode, unlocks, or another similar event occurs. The hang happens in the firing of an event handler, called from “SystemEvents.OnUserPreferenceChanged”. The cause is that OnUserPreferenceChanged is trying to be super nice, and invoke the event in the appropriate context for each event subscriber. That means that if a Control subscribes to the event, the handler will be called on the UI thread. If user code (on a background thread) subscribes, the handler will be called on an arbitrary thread, etc. The problem occurs when, at some point in the past, a Form or Control was created on a background thread. The creation of the control “installed” a WindowsFormsSynchronizationContext as the current SynchronizationContext (this is default behavior). When OnUserPreferenceChanged attempts to Send (Invoke) to the appropriate thread context, it hangs because the WindowsFormsSynchronizationContext is on the wrong thread, and thus has no message pump with which to process messages.

Blah blah blah. Right now you’re thinking “Whatever dude, I’m a web developer, man, I’m just trying to fix this bug in that other jerk’s code.” Fair enough, you can read the linked post for more gory details. What you care about is the hard part. Well, hard for web developers anyway. By the time the app hangs, it’s too late to find out where the problem occurred. In a medium-to-large application, how do you find the control that was created on the wrong thread? Here’s how to do it in a matter of seconds.

1. Name your UI thread. If you’re not already doing this, it’s a good idea in general. I like to call mine “UI”, personally. In your “static void Main()” add this single line of code:

Thread.CurrentThread.Name = "UI";

2. Set a breakpoint deep in the bowels of the BCL. What we want to do is cause our application to break when a WindowsFormsSynchronizationContext gets assigned to the current thread. I cracked open Reflector to look at the constructor for WindowsFormsSynchronizationContext:

And I see that there’s a call to “Application.ThreadContext.FromCurrent()”. Close enough for government work, it’ll do for what I want. I didn’t feel like figuring out how to specify a constructor call when setting a breakpoint. (If you know how, leave a comment so we can all learn!) Add a breakpoint to that method call. In Visual Studio, go to the “Debug” > “New Breakpoint” > “Break at Function…” menu. In the “Function” area type the full path to the function: System.Windows.Forms.Application.ThreadContext.FromCurrent()

When you hit “OK” you’ll get a warning about IntelliSense not finding the specified location. Hit “Yes” to set the breakpoint anyway.

3. Run your application. Depending on what version of Visual Studio you’re running, and whether you’ve got source-level debugging for the Framework turned on, you’ll either get the breakpoint on some code, or you’ll get this message box:

It doesn’t matter, you can press “OK” or “Show Disassembly”, whatever floats your boat. Go to the “Call Stack” debugging window, right-click on the red breakpoint circle located at the top of the stack frame, and select “Breakpoint” > “Filter…”

4. Add a filter to this breakpoint so that it only breaks when the current threads’ name isn’t “UI”.

After you hit “OK”, continue running your application in the debugger. The first time a WindowsFormsSynchronizationContext is created and it’s not on the UI thread, BAM. There’s your problem, and there’s your stack trace allowing you to find the bad code.

This worked like a champ for me today, hopefully you have as much success with it too.

One down-side to LINQ is that, out of the box, it’s geared towards knowing your query structure at compile-time. The values can be dynamic, of course, but it’s assumed that the structure of your query is static. For example, if you want to select a set of "Person" objects from the "People" collection where Person.FirstName starts with "Aar", you could write it as such:

var results = from person in People
              where person.FirstName.StartsWith("Aar")
              select person;

That’s all fine and good, but what about scenarios where you want to dynamically build up your query structure? In our client application we have address books (directories) that include the ability to filter them on any, or nearly any, column:

How would I accomplish this with LINQ? Not easily. Just ask Ayende or Rob Conery, both of whom have blogged about some of their adventures in advanced usage scenarios. Enter the LINQ Dynamic Query sample from Microsoft. As usual, ScottGu’s got a good write-up. In a nutshell, it’s a custom expression tree generator based on a limited (but useful) string-based query grammar. With Dynamic Query I could write the query above like this:

var results = from person in People
              select person;
results = results.Where("FirstName.StartsWith(\"Aar\")");

It solved my problem nicely. Almost. As with my example above about matching FirstName’s, let me ask: how often does a user enter an exact case-sensitive match for what they’re looking for? I can save you the trouble and tell you: it doesn’t matter. It’s an unacceptable requirement for a user to have to match something exactly. It’s already questionable that we don’t automatically use fuzzy matching algorithms.

So what I really want is to specify a StringComparison enum value on the call to "StartsWith":

var results = from person in People
              select person;
results = results.Where("FirstName.StartsWith(\"Aar\", System.StringComparison.OrdinalIgnoreCase)");

Alas, this breaks. LINQ Dynamic Query doesn’t support enum values as parameters to methods. So I added it. I won’t redistribute the sample (I’m pretty sure I can’t, but I don’t care to anyway) so here’s what you need to do to add support for enum parsing. Note that I’ve only tested it with calls to string’s StartsWith(string, StringComparison) method. I don’t know what will happen if you sprinkle enum values in random places throughout your dynamic query. Work on My Machine, your mileage may vary, etc. etc. etc.

1. Download the sample.

2. Crack open the Dynamic.cs source file. It’s scary, but you can do it. Modify it like so (I added the "if (ParseEnumType…"

Expression ParseIdentifier() {
    ValidateToken(TokenId.Identifier);
    object value;
    if (keywords.TryGetValue(token.text, out value)) {
        if (value is Type) return ParseTypeAccess((Type)value);
        if (value == (object)keywordIt) return ParseIt();
        if (value == (object)keywordIif) return ParseIif();
        if (value == (object)keywordNew) return ParseNew();
        NextToken();
        return (Expression)value;
    }
    if (symbols.TryGetValue(token.text, out value) ||
        externals != null && externals.TryGetValue(token.text, out value)) {
        Expression expr = value as Expression;
        if (expr == null) {
            expr = Expression.Constant(value);
        }
        else {
            LambdaExpression lambda = expr as LambdaExpression;
            if (lambda != null) return ParseLambdaInvocation(lambda);
        }
        NextToken();
        return expr;
    }
    // ADD THIS IF STATEMENT
    if (ParseEnumType(out value))
    {
        Expression expr = Expression.Constant(value);
        NextToken();
        return expr;
    }
    if (it != null) return ParseMemberAccess(null, it);
    throw ParseError(Res.UnknownIdentifier, token.text);
}

3. Add the definition for ParseEnumType. This little bit of nastiness is essentially doing a look-ahead to resolve a type name, since most of the parser’s rules are built to process more contextual information (such as a property name of a type, etc.) In our case, we need to attempt to match "Foo.Foo.Foo" to a type name, and if it doesn’t end up resolving, we need to reset the parser back to the beginning of "Foo" to continue parsing.

bool ParseEnumType(out object value)
{
    value = null;

    ValidateToken(TokenId.Identifier);
    Type enumType = null;
    int position = token.pos;
    string typeName = token.text;
    while (enumType == null)
    {
        // Loop until we stop processing identifiers and/or dots
        enumType = Type.GetType(typeName, false, true);
        if (enumType == null)
        {
            NextToken();
            if (token.id == TokenId.Dot)
            {
                typeName += token.text;
                NextToken();
                if (token.id == TokenId.Identifier)
                {
                    typeName += token.text;
                }
                else
                {
                    break;
                }
            }
            else
            {
                break;
            }
        }
    }

    if ((enumType != null) && IsEnumType(enumType))
    {
        NextToken();
        ValidateToken(TokenId.Dot, Res.DotExpected);
        NextToken();
        ValidateToken(TokenId.Identifier, Res.IdentifierExpected);
        value = Enum.Parse(enumType, token.text, true);
        return true;
    }
    else
    {
        SetTextPos(position);
        NextToken();
    }

    return false;
}

4. Add an error "resource" string (but not really a true resource string) to the "Res" static class. We added a new condition, so we need an error message to match.

public const string DotExpected = "'.' expected";

Voila! Make sure your enum values are fully-qualified type names and you’ll be good to go.

Hopefully this works for you as well as it did for me, and I have to say I can’t believe I couldn’t find this on the ‘net, as I imagine this is a very common use-case.

While I can easily understand what Ben’s code is doing, what I couldn’t figure out is why it worked. If you reflect over TempDataDictionary (the type of the Controller.TempData property), you’ll see that the data type it persists to the session is an internal structure.

Ben’s code, however, mocks out the Session to return the expected TempDataDictionary object. By all counts, that should fail, since the TempDataDictionary won’t be getting back the values it expects–it expects the internal map structure.

Well, it turns out I was glossing over one very important fact. TempDataDictionary was written to be smart enough that if the underlying session store either didn’t work, or didn’t provide the right data, TempData will continue to operate as normal–for the current request only. You can see below that if the session data was null or wasn’t the right type, it just creates a new internal map.

(image cut off for space)

One of the benefits of TempData is the cross-request persistence via the session. You might not have known it, but when you call RedirectToAction in your controller action, for example, it’s actually resulting in a 300-level HTTP redirect, which means an entirely new HttpContext for the next request. It’s basically deferring to the browser to perform the redirect.

So, while Ben’s code will definitely work, here’s an extension method that can help with mocking out the session a little more “correctly”:

public static void NullifySessionState(this HttpSessionStateBase session)
{
    SetupResult.For(session[null]).IgnoreArguments().Return(null);
    session[null] = null;
    LastCall.IgnoreArguments();
}

Like Tim, I’ve been using S3 to host my images for the blog, and I wholeheartedly agree with him – the workflow for writing a post sucked big time. This plug-in had been on my //TODO list for a long while now. Somehow I mentioned that fact to Tim on Twitter and he sent me a link to a screenshot of his initial version. My response? Sign me up!

He uploaded his source to CodePlex and I immediately started implementing the remaining features. The result is the 0.9 beta release of the S3 Browser Windows Live Writer plug-in. Give it a download and try it out! Please submit any feature ideas or bugs on the codeplex site, or you can leave a comment here as well.

Unfortunately all of these tools are restricted in one normally insignificant way: they only operate on the currently loaded project(s). For most software this really is insignificant. The entire application can be loaded into the IDE all at once. Sometimes, though, it is a problem–usually when there’s another problem at play: code "bloat" (via Jeff).

If you’ve ever changed a namespace and wanted to simply push the change into every code file in an entire directory branch, PowerShell comes to our rescue with it’s search-and-replace capabilities. I wrote the following "Move-Namespace" function to do just that.

Invoke the function like so: "Move-Namespace *.cs "[current namespace]" "[current class name]" "[new namespace]".

After it completes, any explicit reference will be changed, and any implicit references (using traditional "using [namespace];" statements) will have a new "using [new namespace];" line inserted after the last existing using statement.

Let’s hope you don’t have a code base that requires this function. But if you do, I hope it helps!

Note that this function relies on my "Replace-String" function, found here.

function Move-Namespace(
    $includes = $(throw 'Specify a file filter to use'),
    $oldNamespace = $(throw 'The namespace to replace - i.e. MyCompany.Product'),
    $className = $(throw 'The class name to search for - i.e. MyClass'),
    $newNamespace = $(throw 'The new namespace to add - i.e. MyCompany.Product.Feature'))
{
    # Look for cases of $className
    # or $oldNamespace.$className
    # and replace as necessary

    # First check for assumed "using" statements, and add the using statement
    $results = @{}
    $files = get-childitem -r -i $includes | select-string "(?<!$oldNamespace\.)\b$className\b" -list |% { $_.Path }
    select-string "^using.*;" -path $files | group-object Path | select-object Name, @{Expression={ ($_.Group | measure-object -property LineNumber -max).Maximum }; Name="LastUsingStatement" } |% { $results[$_.Name] = $_.LastUsingStatement }
    foreach ($key in $results.keys)
    {
      $processFile = $true
      $lastUsingIndex = $results[$key]
      $fileContents = get-content $key
      # look for existing using statement and cancel processing this file
      for ($i = 0; $i -lt $lastUsingIndex; $i++)
      {
        if ($fileContents[$i] -match "using $newNamespace;")
        {
          # this file already has the correct using statement, stop processing
          Write-Warning "File $key already has the required using statement, ignoring"
          $processFile = $false
          break;
        }
      }

      if ($processFile)
      {
        $newContents = $fileContents[0..($lastUsingIndex-1)] + "using $newNamespace;" + $fileContents[$lastUsingIndex..$fileContents.Length]
        set-content -path $key -value $newContents
        Write-Host "Successfully updated file $key" -foregroundcolor Green
      }
    }

    # Next check for explicit references
    replace-string "\b$oldNamespace\.$className\b" "$newNamespace.$className" $includes
}

I got some good feedback on the utility, along with some additional feature requests that ran outside the bounds of what the symstore utility offered. That lead me to upgrade my project to include a full-fledged (well, almost) symstore replacement, plus the GUI manager utility.

I’ve published the project tonight on CodePlex as "PSSymbolStore", and I’ve released the initial 0.1 beta release.

So what did I add and what did I change?

PowerShell

PSSymbolStore is now founded on a set of PowerShell cmdlets that replace and extend symstore’s functionality. (Almost: I need some feedback about a few symstore features and how they might work in the PowerShell world. If you’re a symstore wizard – ahem, John – drop me a line.) The initial release includes the following cmdlets, along with full help, including examples:

• Add-Symbols – Adds symbols to the symbol store
• Get-Transaction – Retrieves some or all of the transactions from a symbol store
• Remove-Transaction – Deletes transaction(s) from a symbol store
• Lock-Transaction – Locks transaction(s), preventing them from being deleted with the Remove-Transaction cmdlet
• Unlock-Transaction – Unlocks transaction(s), allowing them to be deleted with the Remove-Transaction cmdlet

Symbol Store Manager

The Symbol Store Manager (formerly "Symbol Server Transaction Manager") is basically the same from a UI perspective, but has been massively gutted. The internal changes (MVP pattern, PowerShell hosting, etc.) are all for the better as they fully enable unit testing, which is coming in a future release. I’m looking for feedback on the UI – what I can improve, etc. It’s really basic right now. I had started adding a search feature using ShuffleText’s Highlight fuzzy search library, but didn’t have time to finish it the way I wanted so I’ve pushed it out to a future release.

vNext

So what’s coming next? I’ve already mentioned unit tests and searching. I’m also kicking around some UI enhancements. Aside from those features, and finishing up some "paperwork" like installs, I don’t currently have a strong feature list. If you have ideas, please either post them as a comment here, or even better on the codeplex project site. For example: would this be more useful as an MMC snap-in instead of a standalone application?

Download PowerShell if you haven’t already, and give PSSymbolStore 0.1 Beta a whirl – I hope it’s useful!

‘Just Say No’ to collocated file dependencies at run time.

Loading file dependencies (like images, etc.) at runtime in a dynamic way can be tricky without resorting to a global information store like the registry. How do you know where your .NET application is “executing from”? You could be loaded via COM into another process, loaded into a .NET application via custom assembly resolution code, or shadow-copied in an ASP.NET application. If you’re depending on collocated files, where should you get them from? Of course this depends on your install strategy and any policy your architecture defines.

Here’s a summary of the different ways you can retrieve a path (whether “C:\foo” or “http://www.foo.com/”) representing an assembly’s “location”. All this information is available on MSDN, I’m just compiling it together here. Nothing original here! Move along…

Actually, the first question is “which assembly”?

1. Assembly.GetAssembly – Retrieves the loaded assembly that defines the specified type.
2. Assembly.GetCallingAssembly – Retrieves the assembly containing the first method up in the call stack. Big warning here: your current method can be expanded inline by the compiler and you might not get the results you expect. If you are going to call GetCallingAssembly and rely on particular results, mark your method with the [MethodImpl(MethodImplOptions.NoInlining)] attribute. Scott Hanselman has a good write-up of the scenario, and an important warning: don’t mess around with the MethodImplAttribute for no reason. Know what you’re doing.
3. Assembly.GetEntryAssembly – The first executed assembly in the AppDomain. If you have a standard WinForms application called “Foobar”, it’ll be the Foobar.exe. If you’re in code that was loaded into another AppDomain but wasn’t executed, it’ll be null.
4. Assembly.GetExecutingAssembly – Gets the assembly that contains the currently executing code. This is the safest way to say “my assembly”.

Once you’re sure you’ve got the correct assembly, you can get it’s location.

1. Assembly.Location – The location of the loaded file that contains the manifest (important note for the few of you who create multi-file assemblies–though here’s some reasons why you’d want to). If it was shadow-copied, it’s the post-copy location. If it was loaded from a byte array (like Reflector does – seriously, have you ever “reflector’d” over Reflector? ) then it’ll return an empty string.
2. Assembly.CodeBase – The originally specified location of the assembly. For example, if you load “C:\Foo.dll” this property will return file:///C:/Foo.dll.
3. AppDomain.BaseDirectory – “The base directory the assembly resolver uses to probe for assemblies.” In PowerShell, for example, this returns “C:\WINDOWS\system32\WindowsPowerShell\v1.0\”.
4. Module.FullyQualifiedName – The location of a particular module in an assembly. Using PowerShell again–the best .NET playground around:
PS C:\> [System.Reflection.Assembly]::GetExecutingAssembly().GetModules()[0].FullyQualifiedName
C:\Windows\assembly\GAC_MSIL\System.Management.Automation\1.0.0.0__31bf3856ad364e35\System.Management.Automation.dll
5. Update: Jeffrey Palermo has one more to add: AppDomain.CurrentDomain.SetupInformation.ApplicationBase.

Of course, if the “collocated file” you’re trying to load is an Assembly, the best choice is to use the built-in assembly resolution via Assembly.Load – it takes into account configuration file redirects, publisher policy, GAC vs. private, and well-defined probing rules. My non-official rule of thumb: always always always try to avoid loading assemblies manually.