Aaron Lerch

Disclaimer: A long time ago, in a galaxy far away, I helped coordinate the Indy Code Camp. We gave away a few donated copies of NDepend as prizes, and while setting that up, Patrick Smacchia offered me a license if I’d be willing to write about my NDepend experiences on my blog. Having heard about NDepend in the past, I happily took him up on it – making sure it was clear that I would write about my experience regardless of whether they were positive or negative. So this is a “sponsored” post, in that I received an NDepend license, but the license donation did not purchase any of the content of this post.

An astute reader will probably look at the date that I helped with the Indy Code Camp and compare it to the date of this post, and figure out that it was about two years ago that Patrick asked me to evaluate NDepend. And I’m not so happy to say that in those two years, I really didn’t use it. But recently I have more time available to me for doing specifically this sort of thing.

I think Scott Hanselman summed up the initial NDepend experience quite well.

Like PowerShell, the first 10 minutes of NDepend is the hardest. It has to click first. There’s the whole "what the hell am I looking at" process, often followed by the "screw this" declaration, followed by a quick uninstallation and a sense of "what happened."

I’m not going to do a comprehensive overview like Scott or others have done – at this point I just can’t do that as I’m still in kind of the “what the hell is this” phase. But it’s slowly beginning to click. For me, two things that click and help me continue on and work to understand this application.

One, I know I need the information NDepend can give me. I may not understand it all immediately, but I’ve been deep in the code of some applications long enough to see (and write) the good, the bad, and the ugly. I need ways to root out the bad and ugly, without having to dive into all the code in-depth. I also need metrics to help show that the good really is good. Especially when you’re working on a team of several people, each with varying opinions and each who writes their own flavor of code. Just because I don’t like someone else’s code doesn’t mean it’s bad code. Metrics can help me separate my aesthetic or organizational concerns from real problems or smells. And then I can make them write it my way anyway.

Two, and more fun than the first is NDepend’s Code Query Language or CQL. In my opinion, this is an easy “hook” to get someone to look closer at NDepend and get past that 10-minute hump. I have seen a developer’s face literally light up when they hear what CQL can do, especially if they’ve done any work with a database and SQL in the past.

NDepend’s website has the best documentation of CQL, even if the docs feel overwhelming at first. There’s also some information about embedding CQL into your code as in-line constraints that NDepend can enforce during your build, though as others have mentioned it’s not a practical solution.

Of immediate interest to me, due to something I’m doing at work, is catching breaking API changes that might accidentally happen during a maintenance release. Patrick covers how to do this here. But as an example, let’s analyze the breaking API changes in StructureMap between version 2.5.4 and 2.6.1.

Note: I got confused at first, because I put both versions of StructureMap into the same directory and renamed the files to include the version number. NDepend didn’t like this and flagged every single method as removed and added. I’m not sure what I did wrong, but it took a bit to figure out, and it sucks for situations where a version number (or a name change) might cause an assembly name not to match, even though it’s functionally the same.

The first thing to do is select the two assemblies to compare – here I’m choosing StructureMap 2.5.4 on the left, and 2.6.1 on the right.

After the NDepend project has been created, I can press ALT+Q to bring up the CQL editor, and enter the following query:

WARN IF Count > 0 IN SELECT METHODS WHERE
IsInOlderBuild AND IsPublic AND (VisibilityWasChanged OR WasRemoved)

It reads pretty well, especially if you’re familiar with SQL. Literally it’s “warn me if methods exist that were in the older build, were public, and the visibility has changed or the method was removed.”

You can see below, 5 methods were “removed” from StructureMap’s public API – in this case, they are literally removed (and not just made internal or private). That means that upgrading from 2.5.4 to 2.6.1 could mean you have to change or recompile your code.

Likewise you can see that no public types were removed, thus no breaking change exists and the CQL query isn’t flagged as a warning.

This is some powerful stuff, and as I begin to incorporate it more and more into my daily workflow I’ll post about how I’m using it.

The newest version supports a console runner, a stand-alone GUI, and full integration into Visual Studio 2005, 2008, and 2010. For small projects that can exist within a single Visual Studio solution, it’s perfect. For larger projects that span multiple solutions, NDepend still allows you to analyze a set of assemblies, the UI is just embedded inside Visual Studio – and the integration is pretty usable for me so far.

A year and a half ago I wrote about the three little words that are critical for a Technical Manager to understand.

Know your limits.

As I look back over the past year and a half, plus the years leading up to it, I am more and more convinced that this is an extremely important concept to put into practice.

Over the past year+, my team has almost doubled in size (plus an intern or two in the summers). We are all working on different features, but on the same (or similar) products, so we weren’t as “scattered” as we were before I split us up. However, juggling as many balls as we have, being an effective technical manager was becoming more and more difficult for me. Most specifically my organizational skills and managing priorities were lacking. I’ve been working hard to manage the team, manage priorities, and keep my technical chops because like at many software companies that started as a small start-up, the technical manager is implicitly expected to manage and be the technical expert.

Eventually I realized that this lifestyle is ultimately unsustainable, and I couldn’t see a light at the end of the tunnel. That’s bad for me, bad for my family, and bad for the company. I needed to recognize that I was moving well outside my limits. I had to make a decision: stop being a technical expert, and just be a true technical manager, or, stop being a manager and remain as a technical expert.

The decision wasn’t hard… I enjoy code way too much.

Ahhh, this feels so much better! Now I can focus on things that have long interested me but I just plain haven’t had time for. Like, for example, digging deep into NDepend to help keep that 10,000 foot view of our products that I couldn’t do before.

Thanks to everybody who came to the PowerShell talk that Matt Hester and I did at Codemash! If you haven’t heard of Codemash or attended it, it’s an extremely well-done conference in Sandusky, Ohio at a huge indoor waterpark. I brought my whole family (including in-laws) along with to enjoy a vacation. The conference itself draws in all sorts of smart people with all sorts of backgrounds, and there have been many interesting sessions, open space sessions, and conversations already. It’s worth way more than the price of admission. (WAY more.)

We tried to tailor our talk to people who have only heard of PowerShell, and people who have limited experience with it. And that worked great because I think that described the majority of people there. We got a lot of great questions, and of course we went well over our 1-hour timeslot. There’s so much to talk about! I wish we could’ve gotten into more advanced topics like the type system, etc.

For my part of the talk, I presented a few demos. You can download them and the slides below. Briefly, the demos were the following:

Using PowerShell from within applications. I extended the Family.Show example application that Vertigo Software wrote by adding “scripting support” using PowerShell. You can see a screenshot I posted here. I also wrote a simple WPF application that gets a list of processes running on the computer, only including those who have a handle count less than 200.

Simple Cmdlet. I wrote a simple Cmdlet as an example. It’s completely non-functional but I included it here for completeness.

Build Scripts with PSake. I have a simple build script with PSake that doesn’t actually build anything, but shows how to define dependencies, prerequisites, etc.

Windows Troubleshooting Platform + Reference Application. Not included in the download (because you can get the source as-is from codeplex), I briefly covered the PSSymbolStore application. It demos using the Windows Troubleshooting Platform, defining more advanced Cmdlets, and building an application on top of PowerShell at the core. You can browse (and/or download) the code here.
As a note, because of the signing requirements of the Windows Troubleshooting Framework, I will leave the code in the application but will remove any UI that invokes the Troubleshooter. It won’t work on any machine but mine unless I have a trusted certificate, which I don’t.

Download the code and slides from our presentation.

See you next year (hopefully)!

Any desktop application I write from now on will contain these two interfaces. They’re useful enough I thought I should share. Also note, with upcoming improvements in .NET 4.0 (or higher) they might be rendered moot. So far, I don’t think they are, as it’s still difficult to test the code itself that performs asynchronous operations.

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?

The importance of context was brought jarringly to my attention the other day. This week was my intern’s last week, and as such he needed to fill out a “self evaluation” for HR. The first part of the eval was a simple 5-column table: various categories for evaluation, 3 boxes for “Did Not Meet”, “Met”, or “Exceeded” expectations, and finally a box for comments. I personally think that’s a pretty hideous way to do a self evaluation, but I’ll ignore that for now. (I’d give myself a “Did Not Meet” for this post!)

My intern, being a pretty humble guy, put an “X” in each “Met” column and left no comments for himself, unsure of what to put. It looked something like this:

So I decided to “help him out” and provide some feedback since I think he did a very good job this summer. I made my edits and sent it back to him with a note saying we’d review it together the next day.

At our daily standup the next morning he looked pretty depressed and dejected, which I noted, but didn’t think too much about. He sheepishly slipped into my office later that morning for our meeting, and only after we started talking did we realize that something was amiss. You see, I’m a native English-speaker who has spent my entire life in North America. As such, I have learned to read and process information from left to right. When I think about data, I put the lower value on the left and the higher on the right: lower < higher.

Unfortunately, while filling out the review I had skimmed the table and just started editing. So what my intern received from me looked like this:

After my intern started breathing again, we had a good laugh about it. Well, I apologized and laughed and he laughed with relief in the “just got a last-minute pardon” kind of way.
There are two lessons here:

1. Don’t make assumptions. (I should’ve read the document more thoroughly.)
2. Understand your user’s context. Present information in a way that flows with how they naturally think.

Recently I’ve been thinking about options for exposing an application automation API for inter process integration scenarios. For example, a desktop application that exposes the ability for other applications to programmatically query information from it and/or invoke commands. I also had a few requirements. Whatever I choose should:

• 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!

No, that’s not a bash command or a regular expression.

#3 will be joining #2 and #1, and we are pumped.
Well, I’m pumped, my wife is just trying not to feel too sick. She’ll be pumped later, like in 5 years.

I’ve had a few people ask me for a recommendation of some resources to learn design patterns. There’s a lot of good stuff “out there”, of course, but my response usually says just three things:

Read pretty much anything this guy writes,
Learn SOLID, and lern it güd. I recommend starting here.
and
Let me know if you have any questions and let’s chat.

If you’re anything like me, you’ll find yourself up until 4 AM reading, reading, and reading as you link from post to post and article to article. I swear one of these days I will find the end of the internet.

I’ve talked before about System.Threading.SynchronizationContext, as well as BeginInvoke/InvokedRequired/IsHandleCreated. In a multi-threaded Windows Forms application they can easily be mis-used, introducing difficult to find bugs.

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.

LINQ rocks. It really does.

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.