Continuous Disintegration

SQL Server Service Broker Guidance

2011-09-20T18:21:00.001-05:00

Don't use it.

Exception Handling? WTF??

2011-08-30T19:07:00.000-05:00

A recent Daily WTF explored a Guard class which throws an ArgumentNullException if a parameter is null. Most of the commenters correctly point out that the code is not a WTF but rather a good practice because it

Enforces the code contract - this parameter is not allowed to be null
Provides better stack trace information
Causes the app to fail fast

One principle at work here is the idea of adding information to an exception. Without guarding against potentially invalid input in this situation, a NullReferenceException will (presumably) be thrown at some point. But why? What's null? What made it null? Even with the stack trace, this can be painful to debug... annoying at the least. An ArgumentNullException cuts straight to the problem and tells us exactly what is wrong. Anytime you can add information to an exception (or potential exception in this case), you should do it*.

I think this is a good principle to follow when deciding whether or not to catch an exception (that you can't recover from) as well. If you can add information by wrapping it in a more specific exception and adding contextual information, you should do so. Otherwise, there's no need to handle and re-throw.

*Well, not if might expose implementation details you want to hide from users.

Considerations for Multi-Client Applications

2011-08-27T19:49:00.000-05:00

Often when dealing with applications/systems that serve multiple clients, we encounter a situation where

Clients share some core functionality and algorithms
Clients have custom logic that extends the core functionality
Clients have customized data structures that extend core data structures

The key to making this work in a maintainable way (that is, without infusing the code with crazy branching statements or writing the whole application in dynamic SQL) is maintaining a distinct separation between core and client.

Here I present components from a simple, hypothetical application that demonstrates such a separation. The application is meant to evaluate whether or not a client should acquire a player for fantasy football. It contains some core functionality for doing the evaluation (it doesn't pick up a player who has never scored a point) and a core data structure that represents a player. There are two clients who extend this core functionality: me and a stupid opponent in my league. The stupid opponent is a Bears fan who only picks up Bears players. I am a player who uses some trivial evaluation strategy and also extends the core data structure with some data that represents my own opinion.

The code shows an example of how to define and extend core functionality. It does not show how to wire everything together (dependency injection) or how to persist custom data. I may explore these topics in future posts. Also note that I called the code repository 'MultiTenancy', but this is more likely something you'll find in multi-instance scenario. I'm using the term 'multi-client' to represent both possibilities.

Duck Typing with Anonymous Types - Part 3

2011-08-15T17:12:00.000-05:00

Continuing my short series, it's time to add some polish to what we have so far.

Overload Resolution

At first I thought overload resolution was going to be a huge pain, but really the compiler does everything for us. As long as we have assigned an implementation with exactly matching parameters for the method that the compiler calls, we're good to go. The necessary modifications to the interceptor fit into a small reflection utility method.

private Delegate GetMethod(IInvocation invocation)

{

    var methodProperty = anonymous.GetPropertyValue(invocation.Method.Name);

    if (methodProperty is Delegate)

    {

        return methodProperty as Delegate;

    }



    var overloads = methodProperty as Delegate[];

    return overloads.Where(m => m.Method.SignatureMatches(invocation.Method)).First();

}

internal static bool SignatureMatches(this MethodInfo method, MethodInfo other)

{

    var theseParameters = method.GetParameters();

    var thoseParameters = other.GetParameters();



    if (theseParameters.Count() != thoseParameters.Count())

    {

        return false;

    }



    foreach (var parameter in theseParameters)

    {

        var parameterIndex = Array.IndexOf(theseParameters, parameter);

        if (!parameter.ParameterType.Equals(thoseParameters[parameterIndex].ParameterType))

        {

            return false;

        }

    }



    return true;

}

Here is the modified IDuck interface and corresponding test (note that by explicitly declaring brains as an object, the compiler will emit code that calls the overload with object parameter(s)):

public interface IDuck

{

    string Color { get; set; }

    Direction Fly();

    Direction Fly(Direction direction);

    string Quack();

    string Quack(int times);

    string Quack(string sound);

    string Quack(object sound);

    string Quack(params object[] sounds);

    object this[string attribute] { get; set; }

}

[Test]

public void CanInvokeOverloadedMethodsWithSomewhatAmbiguousSignatures()

{

    var zombie = new

    {

        Quack = new Delegate[]

        {

            (Func<int, string>)(i => String.Format("{0} BRAAAINS!", i)),

            (Func<string, string>)(s => String.Format("{0} BRAAAINS!", s)),

            (Func<object, string>)(o => String.Format("{0}", o)),

            (Func<object[], string>)(o => String.Format("{0} BRAAAIN OBJECTS!", o.Count()))

        }

    }.As<IDuck>();



    object brains = "BRAAAINS!";



    Assert.That("10 BRAAAINS!" == zombie.Quack(10));

    Assert.That("EAT BRAAAINS!" == zombie.Quack("EAT"));

    Assert.That("BRAAAINS!" == zombie.Quack(brains));

    Assert.That("3 BRAAAIN OBJECTS!" == zombie.Quack(brains, brains, brains));

}

Indexed Properties

I'm not going to go through all the changes I had to make to support an indexed property, but it wasn't very complicated. Basically, if we give our anonymous type a property named Item, it will correspond to an index on an interface (because an indexer is just syntactic sugar around an Item property). This property should be a Delegate[] with a method for the getter and/or setter (depending on the interface contract). The setter won't automatically store values unless we implement it that way. Here are some examples:

[Test]

public void CanInvokeIndexGetter()

{

    var buckshot = new object();



    var duck = new

    {

        Item = new Delegate[]

        {

            (Func<string, object>)(s => buckshot)

        }                     

    }.As<IDuck>();



    Assert.AreSame(buckshot, duck["weakness"]);

}



[Test]

public void CanInvokeIndexSetter()

{

    var isInfected = false;

    var duck = new

    {

        Item = new Delegate[]

        {

            (Action<string, object>)((key,value) => isInfected = true)               

        }   

    }.As<IDuck>();



    duck["disease"] = "bird flu";

    Assert.IsTrue(isInfected);

}



[Test]

public void CanStoreAndRetrieveWithIndexedProperty()

{

    var store = new Dictionary<string, object>();

    var duck = new

    {

        Item = new Delegate[]

        {

            (Func<string, object>)(s => store[s]),

            (Action<string, object>)((s,o) => store[s] = o)

        }

    }.As<IDuck>();



    var feathers = new object();

    duck["feathers"] = feathers;

            

    Assert.AreSame(feathers, duck["feathers"]);

}

Duck Typing Plain Objects

A few fairly simple modifications, and we can support duck typing objects that aren't anonymous types.

public class ScroogeMcDuck

{

    public string Quack()

    {

        return "Bah! Humbug!";

    }

}



[Test]

public void CanInvokeMethod()

{

    var scrooge = new ScroogeMcDuck().As<IDuck>();



    Assert.That("Bah! Humbug!" == scrooge.Quack());

}

Syntax

Casting the function/action type of the method can look kind of ugly, so I made a utility class that we can pass anonymous methods through to return Delegates. We still have to specify parameter types, so it's still pretty crusty, but it's there if we want to use it.

var duck = new

{

    Quack = Anon.Methods

    (

        Anon.Method(() => "Quack!"),

        Anon.Method<int, string>(i => String.Format("{0} quacks!", i))

    )

};

Conclusion

This is a somewhat serviceable solution for ducktyping adaptation of legacy code or quick mocking, especially of data. We haven't made any special considerations for generics, so it may fail in those scenarios. Named parameters will almost certainly cause problems, and we haven't done any performance tuning. I should also note that I used this post by Mauricio Scheffer as a resource when researching how to begin. The code can be found here on github.

Duck Typing with Anonymous Types - Part 2

2011-08-12T15:29:00.000-05:00

Previously I looked at forwarding property calls of an interface to those of an anonymous type instance. Now I'd like to see if we can forward method calls as well. But how? We can't create an anonymous type instance with methods, and we can't assign assign anonymous methods as properties. This doesn't work:

var duck = new

{

    Color = "white",

    Quack = () => "Quack!"

};

but this does:

[Test]

public void CanInvokeMethod()

{

    var duck = new

    {

        Color = "white",

        Quack = (Func<string>)(() => "Quack!")

    };

}

Let's modify our interceptor once again, this time to retrieve a delegate property named the same as the invoked method and invoke it.

internal class DuckTypingInterceptor : IInterceptor

{

    [... snip ...]



    public void Intercept(IInvocation invocation)

    {

        [... snip ...]



        if (invocation.IsMethodCall())

        {

            var method = GetMethod(invocation.Method.Name);

            invocation.ReturnValue = method.DynamicInvoke(invocation.Arguments);

        }

    }



    [... snip ...]



    private Delegate GetMethod(string name)

    {

        return anonymous.GetPropertyValue(name) as Delegate;

    }

}

[Test]

public void CanInvokeMethod()

{

    var duck = new

    {

        Color = "white",

        Quack = (Func<string>)(() => "Quack!")

    };



    var typedDuck = duck.As<IDuck>();



    Assert.That("Quack!" == typedDuck.Quack());

}

It works! Now... what about overloads? This is a bit trickier. We can start by deciding that overloads will be stored as an array of System.Delegates.

[Test]

public void CanInvokeOverloadedMethods()

{

    var launchPad = new

    {

        Fly = new Delegate[]

        {

            (Func<Direction>)(() => Direction.West),

            (Func<Direction, Direction>)(d => d)

        }

    };



    var launchPadMcQuack = launchPad.As<IDuck>();



    Assert.That(Direction.West == launchPadMcQuack.Fly());

    Assert.That(Direction.South == launchPadMcQuack.Fly(Direction.South));

}

A modified GetMethod method in our interceptor allows the test to pass.

private Delegate GetMethod(IInvocation invocation)

{

    var methodProperty = anonymous.GetPropertyValue(invocation.Method.Name);

    if (methodProperty is Delegate)

    {

        return methodProperty as Delegate;

    }



    var overloads = methodProperty as Delegate[];

    return overloads.Where(

        m => m.Method.GetParameters().Count() == invocation.Arguments.Count()).First();

}

This is obviously a naive implementation - overload resolution is extremely difficult. This will fail for overloads with the same number of parameters differentiated by type, methods with the params keyword, and methods with out/ref parameters. For now, though, we have something that will work well for very simple interfaces. In my final post, I'll try to make the overload resolution a little smarter and handle one other scenario I haven't talked about - indexed properties.

Duck Typing with Anonymous Types

2011-08-12T12:01:00.000-05:00

If you can create an anonymous method and an anonymous type, why not an 'anonymous class'? Wouldn't it be nice to be able to plug properties and methods into and object and then consume that object like any other class or interface?

What we're talking about is essentially duck typing (with strongly-typed ducks). There are examples all over of how to do this, especially with Castle Dynamic Proxy. This is my implementation of the same.

First let's look at a test:

public interface IDuck

{

    string Color { get; }

    Direction Fly();

    Direction Fly(Direction direction);

    string Quack();

}



[Test]

public void CanStubColorProperty()

{

    var rubberDuck = new { Color = "yellow" };

    var typedRubberDuck = rubberDuck.As<IDuck>();



    Assert.That(typedRubberDuck.Color == "yellow");

}

That As<IDuck> part is an extension method that does nothing right now, so this test will fail. What we want that extensions method to do is to return a proxy that implements the IDuck interface and forwards the method/property calls on to our anonymous type instance. Using Castle Dynamic Proxy, we can start creating this:

internal class DuckTypingInterceptor : IInterceptor

{

    private readonly object anonymous;



    public DuckTypingInterceptor(object anonymous)

    {

        this.anonymous = anonymous;

    }



    public void Intercept(IInvocation invocation)

    {

        if (invocation.IsGetter())

        {

            var property = invocation.PropertyName();

            invocation.ReturnValue = anonymous.GetPropertyValue(property);

        }

    }

}

There are some extension methods in there to help with reading method names and reflection, but it's pretty simple - when someone tries to get a property value from the proxy, we give back the value of the property on the anonymous object. Now we can implement that As<TDuck> extensions method:

public static TDuck As<TDuck>(this object anonymous) where TDuck : class

{

    var proxyGenerator = new ProxyGenerator();

    var objectImplementingDuckInterface =

        proxyGenerator.CreateInterfaceProxyWithoutTarget(typeof(TDuck), new DuckTypingInterceptor(anonymous));



    return objectImplementingDuckInterface as TDuck;

}

Now the test passes! Great, now what if that color property had a setter? Let's whip up some code to set the property on that anonymous type instance too:

[ ... some code that attempts to forward a setter invocation to the anonymous object via reflection ... ]

[Test]

public void CanSetColorProperty()

{

    var lameDuck = new { Color = "whocares" };

    var typedLameDuck = lameDuck.As<IDuck>();



    typedLameDuck.Color = "blue";



    Assert.That("blue" == typedLameDuck.Color);

}

The problem is, anonymous types don't have setters on the their properties. So we'll just set the backing field, right? Nope... anonymous type properties have readonly backing fields. They are immutable. We'd really like our proxy to behave like the interface it supposedly implements, so we hack around a bit and come up with this:

internal class DuckTypingInterceptor : IInterceptor

{

    private readonly object anonymous;

    private readonly IDictionary<string, object> properties = new Dictionary<string, object>();



    public DuckTypingInterceptor(object anonymous)

    {

        this.anonymous = anonymous;

    }



    public void Intercept(IInvocation invocation)

    {

        if (invocation.IsGetter())

        {

            var property = invocation.PropertyName();

            invocation.ReturnValue = GetPropertyValue(property);

        }



        if (invocation.IsSetter())

        {

            properties[invocation.PropertyName()] = invocation.Arguments[0];

        }

    }



    private object GetPropertyValue(string property)

    {

        if (properties.ContainsKey(property))

        {

            return properties[property];

        }



        return anonymous.GetPropertyValue(property);

    }

}

Now we're mixing in a dictionary of property values with the mutable anonymous object instance to give the feel of a single object with IDuck capabilities.

So what about methods? Well it would be nice if we could construct anonymous types with lambas, like

var duck = new

{

    Color = "white",

    Quack = () => "Quack!"

};

but if we try that, the compiler will yell at us because we "Cannot assign lambda expression to anonymous type property". There is something we can do, however, and I'll cover that in my next post.

Mercurial / hg-git / Github Setup Link

2011-06-19T11:20:00.003-05:00

This is just so I don't forget or lose it: this post has probably the best guide to getting TortoiseHg set up as a github client on Windows:

james mckay dot net - TortoiseHg as a github client on Windows

Apparently I don't know how to use Google, because I always struggle to find this.

UPDATE:
Be careful not to wrap the hggit extension path in quotes in the mercurial config file *even if the path has a directory with a space in it*. I was setting mine like this:

[extensions]

hggit = "C:\ABC DEF\hg-git\hggit"

but that was causing this error:

*** failed to import extension hggit from "C:\ABC DEF\hg-git\hggit": [Errno 22] Invalid argument

Removing the quotes fixed the problem:

[extensions]

hggit = C:\ABC DEF\hg-git\hggit

Serializing Anonymous Methods

2010-09-10T22:42:00.002-05:00

I’m taking some time off from not blogging to do a little blogging. I hope this doesn’t inconvenience absolutely nobody.

I was doing some [binary] serialization work recently when I came across a problem – I wanted to serialize objects with delegate fields that were populated with anonymous methods at runtime. To wit, I had types like this:

public delegate void MakeMove();



public class AdrianPeterson

{

    public int GameOneYards { get; set; }

    public Football Ball { get; set; }

    public MakeMove Move { get; set; }

}

Populated like this:

var explicitDirections = new List<string> { "left", "right", "left" };



var ap = new AdrianPeterson();

var apName = ap.GetType().Name;

ap.GameOneYards = 87;

ap.Move = () => Moves.Weave(apName, explicitDirections);

So, I pop a [Serializable] on AdrianPeterson (and Football), and I’m set, right? Wrong. Wrong like getting away from running AP in the second half when the only receiving threat you have is being blanketed by the Saints defensive backfield. You end up with an exception like this:

System.Runtime.Serialization.SerializationException: Type 'BlahBlahBlah+<>c__DisplayClass2' in Assembly 'YadaYadaYada' is not marked as serializable.

Ah, of course, the backing field for the ‘Move’ property holds an instance to an object with a runtime type of ‘BlahBlahBlah+<>c__DisplayClass2’ – the compiler-generated class that encapsulates the anonymous method and its scope (or something like that… let’s not get too technical). That class isn’t marked as serializable. Hence the exception. Crap!

No problem, a quick google search gave me this code as the first result. It works very well, except it doesn’t handle fields declared as abstract types. I made a little modification, then I started to get the dreaded refactoring itch. I started looking at the if/else if/else mess that was mirrored in both the deserialization constructor and ‘GetObjectData’ method and thought “clearly these are strategies determined by the type”. And I thought a little more, “this looks like a good place for a chain of responsibility or something like that.” And I thought a little more, and I realized that the serialization architecture in the .NET framework is built to handle this exact situation!

All I really had to do was handle serialization of classes not marked with the aforementioned attribute, and the rest fell into place. Relevant classes:

public class UnattributedTypeSurrogate : ISerializationSurrogate

{

    private const BindingFlags publicOrNonPublicInstanceFields = 

        BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public;



    public void GetObjectData(object obj, 

        SerializationInfo info, StreamingContext context)

    {

        var type = obj.GetType();

        foreach (var field in type.GetFields(publicOrNonPublicInstanceFields))

        {

            var fieldValue = field.GetValue(obj);

            var fieldValueIsNull = fieldValue != null;

            if (fieldValueIsNull)

            {

                var fieldValueRuntimeType = fieldValue.GetType();

                info.AddValue(field.Name + "RuntimeType", 

                    fieldValueRuntimeType.AssemblyQualifiedName);

            }

            

            info.AddValue(field.Name + "ValueIsNull", fieldValueIsNull);

            info.AddValue(field.Name, fieldValue);

        }

    }



    public object SetObjectData(object obj, 

        SerializationInfo info, StreamingContext context, ISurrogateSelector selector)

    {

        var type = obj.GetType();

        foreach (var field in type.GetFields(publicOrNonPublicInstanceFields))

        {

            var fieldValueIsSerializable = info.GetBoolean(field.Name + "ValueIsNull");

            if (fieldValueIsSerializable)

            {

                var fieldValueRuntimeType = info.GetString(field.Name + "RuntimeType");

                field.SetValue(obj, 

                    info.GetValue(field.Name, Type.GetType(fieldValueRuntimeType)));   

            }

        }



        return obj;

    }

}



public class UnattributedTypeSurrogateSelector : ISurrogateSelector

{

    private readonly SurrogateSelector innerSelector = new SurrogateSelector();

    private readonly Type iFormatter = typeof (IFormatter);



    public void ChainSelector(ISurrogateSelector selector)

    {

        innerSelector.ChainSelector(selector);

    }



    public ISerializationSurrogate GetSurrogate(

        Type type, StreamingContext context, out ISurrogateSelector selector)

    {

        if (!type.IsSerializable)

        {

            selector = this;

            return new UnattributedTypeSurrogate();

        }

        return innerSelector.GetSurrogate(type, context, out selector);

    }



    public ISurrogateSelector GetNextSelector()

    {

        return innerSelector.GetNextSelector();

    }

}

Usage is like this:

var formatter = new BinaryFormatter();

formatter.SurrogateSelector = new UnattributedTypeSurrogateSelector();

formatter.Serialize(serializedAP, adrianPeterson);

This hasn’t been rigorously tested, and there is at least one case where I know it will fail – if the formatter that is doing the serialization gets captured in the compiler-generated class for the anonymous method (which can easily happen if the formatter is a field in the outer class and the anon. method uses another field from that class).

Full code, with tests, can be found here.

Micro Fluency

2010-05-01T14:59:00.004-05:00

I’ve been having a lot of conversations at work lately about how comments are a code smell, and if you’re not writing self-documenting code, ur doin it rong.
Then I found myself in a position I’ve been in quite a few times… The general description is this: I have a method that takes two parameters. The action the method performs is best written in English in the form “{SomethingTheObjectDoesWith} {parameter1} {On/With/For/SomeOtherPreposition} {parameter2}”. The only way to name the method is “SomethingTheObjectDoesOn/With/For(parameter1, parameter2)”. It seems like I run into this situation too often. The API for all of the concerned code doesn’t necessitate building out a huge fluent interface for readability, but it would be nice to have things read just a little better in this case.
An example is certainly in order. I have an ASP.NET server control that activates a certain index on an associated MultiView. In order to let client code know whether or not it activates an index, I have this method:

public bool ActivatesViewOn(int viewIndex, string multiViewId)

{

    // Some logic that determines if the control activates the specified view

}

Here is the method in use:

filterPanel.Visible = itemClicked.ActivatesViewOn(0, contentMultiView.ID);

This is *kinda* self-documenting, but it doesn’t really read as nicely as it could. So I did this fairly minor refactoring in the control:

public IActivateViewOn ActivatesView(int viewIndex)

{

    return new ActivateViewOn(viewIndex);

}



public interface IActivateViewOn

{

    bool On(string multiViewId);

}



private class ActivateViewOn : IActivateViewOn

{

    private readonly int viewIndex;



    public ActivateViewOn(int viewIndex)

    {

        this.viewIndex = viewIndex;

    }



    public bool On(string multiViewId)

    {

        // Some logic that determines if the control activates the specified view 

    }

}

And now the calling code looks like:

filterPanel.Visible = itemClicked.ActivatesView(0).On(contentMultiView.ID);

So here I’ve created a miniature fluent interface that is specific to this method. But at what cost? Have I added needless complexity to the control? Arguably, I’ve made the client code more readable but the control code harder to maintain. Here’s how I see it:

PRO: Consuming code is easier to read.
PRO: Adding nested types (the IActivateViewOn interface and ActivateViewOn class) is no more complicated that adding methods. Basically, I get a nice fluent syntax by breaking my uglier method into a few smaller ones.
PRO: The added private class isn’t exposed to the client, so that piece doesn’t complicate the external API. The added interface is only exposed as a nested class on the control, so it doesn’t pollute the controls namespace.
PRO: I can modify this further pretty easily to keep my client code very readable as dictated by usage. Though it would probably be overkill to have itemClicked.Activates.FirstView.On(someMultiView), the option is there and the syntax could be easily produced.
PRO: I could rename the nested types for even more clarity in the control’s code.
CON: The IActivateViewOn interface might not aid discovery as a return value as much as bool might. I’m reaching here… I personally think the fluent interface is more discoverable. But how do I know I can eventually get the data that I want?
CON: A developer maintaining the control will think “what the hell is this?!?”.

When an Object Isn’t an Object

2010-04-13T22:48:00.004-05:00

I really wish there were more guidance on how to handle static reflection situations. Some kind of helper library would be nice. I’m actually surprised one doesn’t exist given its usefulness and the quirks involved. Consider this scenario – you’re reflecting over the details of a method call and the parameters passed. You actually care about the values that have been passed. How do you discover them?
It goes something like this, I think:

var argument = GetExpression();

if (argument.Type.IsValueType)

{

    argument = Expression.Convert(argument, typeof(object));

}



var getValueExpression = Expression.Lambda<Func<object>>(argument);

var getValue = getValueExpression.Compile();

var value = getValue();

I found that here.

If you don’t explicitly convert the value type to an object, you’ll get an exception that will confuse you (something to the effect of “Expression of type 'System.Decimal' cannot be used for return type 'System.Object'”). It’s confusing because, c’mon, isn’t everything a System.Object? If a function returns object, can’t you return anything? Well, no. And I’m guessing from what Eric Lippert also says here, baking the conversion rules for C# (in this case, that almost everything is convertible to object and so C# does it implicitly) or VB or any other .NET language into LINQ would be doing a disservice to the other languages.

Teaser

2010-04-13T14:00:00.002-05:00

These tests all pass:

[Test]

[ExpectedException(typeof(AssertionException))]

public void ThrowsAssertionExceptionForWrongArgument()

{

    Expect.Call(() => Console.WriteLine("A specific string."));

    StaticClass.CodeUnderTestThatCallsConsoleWriteLine();

    Verify.AllExpectations();

}



[Test]

public void VerifiesCallWithoutActuallyPerformingTheCall()

{

    Expect.Call(() => Console.WriteLine("You shouldn't see me."));

    StaticClass.CodeUnderTestThatCallsConsoleWriteLine();

    Verify.AllExpectations();

}



[Test]

public void PerformsAlternativeAction()

{

    Expect.Call(() => Console.WriteLine("YOU SHOULDN'T SEE THIS")).IgnoreArguments()

        .Do(() => Console.WriteLine("You should see this instead."));

    StaticClass.CodeUnderTestThatCallsConsoleWriteLine();

    Verify.AllExpectations();

}



[Test]

public void IgnoresArguments()

{

    Expect.Call(() => Console.WriteLine("")).IgnoreArguments();

    StaticClass.CodeUnderTestThatCallsConsoleWriteLine();

    Verify.AllExpectations();

}



[Test]

public void InterceptsBothCalls()

{

    Expect.Call(() => Console.WriteLine("")).IgnoreArguments();

    StaticClass.CallsConsoleWriteLineTwice();

    Verify.AllExpectations();

}



[Test]

public void InterceptsOnlyOneOverload()

{

    Expect.Call(() => Console.WriteLine("IGNORED")).IgnoreArguments();

    StaticClass.CallsTwoOverloads();

    Verify.AllExpectations();

}

Where StaticClass looks like this:

public static class StaticClass

{

    public static void CodeUnderTestThatCallsConsoleWriteLine()

    {

        Console.WriteLine("You shouldn't see me.");

    }



    public static void CallsConsoleWriteLineTwice()

    {

        Console.WriteLine("You shouldn't see me.");

        Console.WriteLine("You shouldn't see me.");

    }



    public static void CallsTwoOverloads()

    {

        var characters = "You SHOULD see me.".ToCharArray();



        Console.WriteLine("You shouldn't see me.");

        Console.WriteLine(characters);

    }

}

And the console output as shown by ReSharper is this:

VS Extensibility - It's So Easy!

2010-03-27T16:51:00.008-05:00

(Note: This is an old post that was stuck in my backlog. I am publishing it now with the intent of writing more VS extensibility posts.)

I have a colleague who laments the desire of developers to have (and tool developers to put) ‘everything in the IDE’. Anyone who has struggled with integrated source control fussing up a solution structure can probably identify with this view to some degree. Still, anyone who has used the NUnit GUI test runner for lack of having ReSharper or TestDriven.NET has had a taste of the case for IDE integration. When building small custom tools to enhance developer productivity and make it easy to perform mechanical tasks, why not stick them in Visual Studio? It turns out, it’s pretty easy to do.

Consider a situation in which a developer has user accounts for each tenant of a multitenant application. These accounts get deactivated after a period of non-use, so they need to get reactivated in order for the developer to troubleshoot problems that manifest only for a specific tenant. The developer usually just runs a script that resets the account to active; it’s about as simple as a maintenance task could be for a dev. Still, wouldn’t it be nice to have an easy way to track down the script and execute it? And wouldn’t it be nice to make sure all the developers used a standard method of performing this reset to prevent possible anomalies? We can make a little Visual Studio tool window with a button to execute this script. The tool window can be easily located in the Visual Studio menus.

First, create a Visual Studio Integration Package project

This will bring up a wizard, which is pretty self-explanatory. In this example, we’re creating just a tool window:

From there, it’s just a matter of creating a user control to do our bidding. The control is automatically included in the integration package project and named ‘MyControl’ by default. Integration and interoperability with VS is achieved through a Microsoft.VisualStudio.Shell.Package class (named ‘{PackageName}Package’ by default) and a wrapper class (‘MyToolWindow’ by default) which inherits from Microsoft.VisualStudio.Shell.ToolWindow and exposes the control to the IDE through the Window property.

I’ll spare the boring details on the implementation of this example control. The code can be found here.

Part of what makes developing the tool window so easy is the debugging experience – running the project launches an experimental hive with our custom tool window installed! Just go to View > Other Windows and select the User Reactivation tool:

This example featured a hardcoded backend with no configuration options. In the future, I’ll explore how to outfit your extensibility projects with configuration.

Defeating the Purpose of a DSL

2010-03-02T01:12:00.002-06:00

First, I neglected to mention in my previous post that I found Paul Cowan's blog to be a tremendous help in figuring out how build a DSL with Boo and Rhino DSL.

Second, I wanted to point out that, because this is an internal DSL written in Boo, it's still possible to use familiar programming constructs in the DSL scripts. For example, I could dynamically generate the team definitions from some other datasource, like so:

stats = GetData()



for row as DataRow in stats.Rows:

define row["name"]:

defense Determine.DefenseFromRanking(cast(int,row["defenseRanking"]))

pass_offense Determine.PassOffenseFromRanking(cast(int,row["passOffenseRanking"])), with_qb_type(Determine.QbTypeFromRatingAndExperience(cast(double,row["qbRating"]), cast(int,row["qbExperience"])))

run_offense Determine.RunOffenseFromRanking(cast(int,row["runOffenseRanking"]))

where GetData() returns a DataTable with multiple team statistics, and Determine is a static class that gets the name of different team components based on relevant stats.

The meta methods that define the keywords won't work as is for this. Remember, they're operating on the AST. In this case, the parameter types simply need to be relaxed from StringLiteralExpression to Expression. Here's the new run_offense meta method as an example:

[Meta]

public static def run_offense(expression as Expression):

return [|

_currentTeam.RunOffense = $expression

|]

So, string literals and method calls both work here. One thing that slightly limits the extensibility of the language in this matter is the use of the implicit base class as a container for the script. The body of the script (minus any import statements) goes directly into the implementation of an abstract method declared on the base class, so extending the language by adding methods directly to the script is out. Other than that, everything should work like normal. All the constructs of the language are available. Of course, doing something like what's listed above sort of defeats the purpose of creating a language for easy data scripting in the first place, as it isn't very readable or maintainable...

Building a Simple Data Definition DSL with Boo

2010-02-25T22:47:00.002-06:00

In my daily work, I find myself writing a lot of one-off SQL scripts to handle various data issues. In particular, I've had to tweak existing sets of metadata with scripts that look something like the following:

DECLARE     @SomeId INT

DECLARE     @SomeOtherId INT



SELECT      @SomeId = SomeTableId 

FROM        SomeTable 

WHERE       SomeName = 'Something'



SELECT      @SomeOtherId = SomeOtherTableid 

FROM        SomeOtherTable 

WHERE       SomeOtherName = 'SomethingElse'



IF NOT EXISTS(

    SELECT  1 

    FROM    SomeMetadataTable 

    WHERE   Name = 'MetadataName')

BEGIN

    INSERT INTO SomeMetadataTable

        (Name, Property1, Property2)

    VALUES 

        ('MetadataName', @SomeId, @SomeOtherId)

END

ELSE

BEGIN

    UPDATE  SomeMetadataTable

    SET     Property1 = @SomeId

        ,   Property2 = @SomeOtherId

    WHERE   Name = 'MetadataName'

END

Just writing a few of these gets to be tedious, and master scripts to populate entire tables are large, difficult to maintain blobs of SQL.

At the end of last year, I nabbed myself some copies (digital and physical) of Ayende's excellent DSLs in Boo. Having thought before that I might use some of the tools in the SQL Server Modeling space to build a DSL to simplify the scripting of such metadata, I decided to see how easily something workable could be built with Boo. There were a few stumbling blocks along way, mostly regarding my inexperience with Boo and my inability to download and compile Rhino DSL (I'm not used to git, and a directoy with a space in the name wasted some of my time). Once I was past those problems, I found the going very easy.

I wrote this exploratory example before the NFL championship games this year, so I chose to create a language that might describe the attributes of a football team. Here is the final script I ended with:

define "New York Jets":

    defense "Superb"

    pass_offense "Game Management", with_qb_type("Rookie")

    run_offense "Power"



define "Minnesota Vikings":

    defense "Solid"

    pass_offense "High-Powered", with_qb_type("Aging Veteran")

    run_offense "Dynamic"



define "Indianapolis Colts":

    defense "Speedy"

    pass_offense "High-Octane", with_qb_type("Elite Veteran")

    run_offense "Anemic"



define "New Orleans Saints":

    defense "Opportunistic"

    pass_offense "Explosive", with_qb_type("Rising Star")

    run_offense "Serviceable"

The easiest way to define 'keywords' like define and defense is through meta methods. Meta methods process AST nodes and return AST nodes during compilation. The meta method for define looks like this:

[Meta]

public static def define(expression as StringLiteralExpression, block as BlockExpression):	

    return [|

        _currentTeam.Name = $(expression.Value)	

        DefineTeam($block)

    |]

I'm using quasi-quotation here, which basically means that Boo will turn that block of code that I'm returning into an appropriate AST node. So, in this case, when the compiler encounters 'define', it will take the following string and the block that follows that and transform it into a call that sets a property (Name) on a class variable (_currentTeam) with the string, followed by a call to a class method (DefineTeam) that takes the block as an argument. Yeahhhhhhhhhhh, that's confusing. It takes a little bit of time to get your head around exactly what is going on, but once you do, you can crank out meta methods like mad.
So where did that field and method come from? I'm using Ayende's Rhino DSL library to create an 'implicit base class' for the script. The meta methods ultimately call fields and methods that are defined on this base class from which the script inherits. In this case, I'm doing something that might be unorthodox or bad practice by combining all the team definitions together and storing them in a list. In most examples I've seen, the team definitions would be in four different script. For this spike, I went with something quick and dirty. The SQL I'm generating isn't being written to file anywhere or executed; I'm just kicking it out to the console. Here's the script's base class in its entirety:

import System

import Boo.Lang.Compiler.Ast



public abstract class TeamDefinitionScript:



protected currentNumber as int



public def constructor():

    CurrentTeam = TeamModel()



[Property(Teams)]

protected _teams as List[of TeamModel] = List[of TeamModel]()



[Property(CurrentTeam)]

protected _currentTeam as TeamModel



abstract def Prepare():

    pass



protected def DefineTeam(block as callable):

    block()

    Teams.Add(CurrentTeam)

    currentNumber++



    print "DECLARE @DefenseId${currentNumber} INT"

    print "SELECT  @DefenseId${currentNumber} = DefenseId FROM Defense WHERE DefenseTypeName = '${CurrentTeam.Defense}'"

    print ""

    print "DECLARE @RunOffenseId${currentNumber} INT"

    print "SELECT  @RunOffenseId${currentNumber} = RunOffenseId FROM RunOffense WHERE RunOffenseTypeName = '${CurrentTeam.RunOffense}'"

    print ""

    print "DECLARE @PassOffenseId${currentNumber} INT"

    print "DECLARE @QbTypeId${currentNumber}	  INT"



    print "SELECT  @QbTypeId${currentNumber} = QbTypeId FROM QbType WHERE QbTypeName = '${CurrentTeam.QbType}'"

    print "SELECT  @PassOffenseId${currentNumber} = PassOffenseId FROM PassOffense WHERE PassOffenseTypeName = '${CurrentTeam.PassOffense}' AND QbTypeId = @QbTypeId"

    print ""

    print "IF NOT EXISTS (SELECT 1 FROM Teams WHERE TeamName = '${CurrentTeam.Name}')"

    print "BEGIN"

    print "    INSERT INTO Teams (TeamName, DefenseId, RunOffenseId, PassOffenseId)"

    print "        VALUES        (${CurrentTeam.Name}, @DefenseId${currentNumber}, @RunOffenseId${currentNumber}, @PassOffenseId${currentNumber})"

    print "END"

    print "ELSE"

    print "BEGIN"

    print "    UPDATE Teams"

    print "    SET    DefenseId = @DefenseId${currentNumber}"

    print "    ,      RunOffenseId = @RunOffenseId${currentNumber}"

    print "    ,      PassOffenseId = @PassOffenseId${currentNumber}"

    print "    WHERE  TeamName = '${CurrentTeam.Name}'"

    print "END"

    print ""



[Meta]

public static def define(expression as StringLiteralExpression, block as BlockExpression):	

    return [|

        _currentTeam.Name = $(expression.Value)	

        DefineTeam($block)

    |]



[Meta]

public static def defense(expression as StringLiteralExpression):

    return [|

        _currentTeam.Defense = $(expression.Value)	

    |]



[Meta]

public static def pass_offense(expression as StringLiteralExpression, withQbType as MethodInvocationExpression):	

    return [|

        _currentTeam.PassOffense = $(expression.Value)	

        $withQbType

    |]



[Meta]

public static def run_offense(expression as StringLiteralExpression):

    return [|

        _currentTeam.RunOffense = $(expression.Value)	

    |]



[Meta]

public static def with_qb_type(qbType as StringLiteralExpression):

    return [|

        _currentTeam.QbType = $(qbType.Value)

    |]

(NOTE: Whitespace is significant by default in Boo, and I've tinkered with it a bit here, so this wouldn't actually compile.)

That's really all there is to it. This class contains the bulk of the work. The meta methods are static, and don't need to be members on the base class, but it's a little easier to follow the flow of method calls this way. Now all I need to do is wire up the implicit base class and run the script. Rhino DSL does this for me:

import System

import System.IO

import Rhino.DSL



factory = DslFactory()

factory.BaseDirectory = System.AppDomain.CurrentDomain.BaseDirectory

factory.Register[of TeamDefinitionScript](TeamDefinitionDslEngine())



scriptPath = Path.Combine(factory.BaseDirectory, "Scripts\\TeamDefinitions.boo")



script = factory.Create[of TeamDefinitionScript](scriptPath)

script.Prepare()

(NOTE: This script runner console is a different assembly than the one with the script base class.)

I run it, and this is the output (for the last declaration only):

DECLARE @DefenseId4 INT

SELECT  @DefenseId4 = DefenseId FROM Defense WHERE DefenseTypeName = 'Opportunistic'

DECLARE @RunOffenseId4 INT

SELECT  @RunOffenseId4 = RunOffenseId FROM RunOffense WHERE RunOffenseTypeName = 'Serviceable'

DECLARE @PassOffenseId4 INT

DECLARE @QbTypeId4        INT

SELECT  @QbTypeId4 = QbTypeId FROM QbType WHERE QbTypeName = 'Rising Star'

SELECT  @PassOffenseId4 = PassOffenseId FROM PassOffense WHERE PassOffenseTypeName = 'Explosive' AND QbTypeId = @QbTypeId



IF NOT EXISTS (SELECT 1 FROM Teams WHERE TeamName = 'New Orleans Saints')

BEGIN

INSERT INTO Teams (TeamName, DefenseId, RunOffenseId, PassOffenseId)

VALUES        (New Orleans Saints, @DefenseId4, @RunOffenseId4, @PassOffenseId4)END

ELSE

BEGIN

UPDATE Teams

SET    DefenseId = @DefenseId4

,      RunOffenseId = @RunOffenseId4

,      PassOffenseId = @PassOffenseId4

WHERE  TeamName = 'New Orleans Saints'

END

Pretty simple. Boo makes everything so easy, you can concentrate on developing syntax and language features instead of hacking out code.

A Single-Featured App – Introducing ‘Queue View’

2009-09-25T21:48:00.003-05:00

I’ve been working with NServiceBus at work lately, and it’s useful to be able to look at the messages that are landing in the queues. Unfortunately, the MMC snap-in provided by Microsoft is woefully inadequate when it comes to this task. There are some commercial tools available, but I thought I should be able to find a free tool out there somewhere with this seemingly simple functionality.

I found Msmq Studio, a nice little app that enables you to do many different queue management tasks both locally and remotely. However, it doesn’t seem to work on my machine now (or any of the servers at work), though it did at one time. I need something reliably do one simple thing, so I decided to take the opportunity to experiment with WPF, a platform for which I’ve never written an app. The result is what I’ve tentatively titled ‘Queue View’:

This app does one thing and one thing only – it shows, in XML format, the contents of messages in private queues on the local machine (assuming, of course, the messages have been serialized and stored in XML). Here is some of the relevant code:

public class MessageQueueGateway : IMessageQueueGateway

{

    #region IMessageQueueGateway Members



    public MessageQueue[] GetPrivateQueuesByMachineName(string machineName)

    {

        return MessageQueue.GetPrivateQueuesByMachine(machineName);

    }



    #endregion

}



public class PlainXmlMessageFormatter : IMessageFormatter

{

    #region IMessageFormatter Members



    public bool CanRead(Message message)

    {

        return true;

    }



    public object Read(Message message)

    {

        XmlTextReader xmlReader = new XmlTextReader(message.BodyStream)

        {

            WhitespaceHandling = WhitespaceHandling.Significant,

            ProhibitDtd = true

        };



        var xml = XDocument.Load(xmlReader);



        return xml.ToString();

    }



    public void Write(Message message, object obj)

    {

        throw new NotImplementedException();

    }



    #endregion



    #region ICloneable Members



    public object Clone()

    {

        throw new NotImplementedException();

    }



    #endregion

}

Because of the way I used it, there really was no reason to make PlainXmlMessageFormatter implement the IMessageFormatter from System.Messaging, but I figured, “Why the hell not?”

In the UI, the main form’s controller has an event handler that looks like this:

private void view_MessageSelected(object sender, MessageSelectedEventArgs e)

{

    selectedMessage = (from message in selectedQueue.GetAllMessages()

                       where message.Id == e.SelectedMessageIdentifier.FullIdentifier

                       select message).SingleOrDefault();



    var messageBodyFormatter = new PlainXmlMessageFormatter();

    var messageBody = messageBodyFormatter.Read(selectedMessage).ToString();



    view.DisplayMessageBody(messageBody);

}

You can get the code here. The solution was created in VS 2010 Beta 1. Binaries are included in the ‘Build’ folder. This is essentially pre-alpha software. If you run it on a machine that doesn’t have .NET 3.5 or MSMQ 3.0 installed, it will probably explode.

Adapting DataRow to IDataRecord

2009-07-18T17:33:00.002-05:00

You can find code for adapting a DataRow to the IDataRecord interface all over the place. One scenario in which this might be useful is [when the dregs of coding society are forced to perform] mapping the results of a database call to a custom object with the results sometimes coming back as a DataSet and sometimes as a DataReader.

IDataRecord has a lot of members that you probably wouldn’t use, simply because they are for retrieving strongly-typed values from the record based on numeric index. You’re probably doing these conversions manually and getting the values by named index. If that’s the case, why not constrain the consumption of these types with the following interface:

public interface IIndexedDataRecord

{

    object this[string name] { get; }

}

and these adapters:

public class DataReaderAdapter : IIndexedDataRecord

{

    private readonly IDataReader reader;



    public DataReaderAdapter(IDataReader reader)

    {

        this.reader = reader;

    }



    public object this[string name]

    {

        get { return reader[name]; }

    }

}



public class DataRowAdapter : IIndexedDataRecord

{

    private readonly DataRow row;



    public DataRowAdapter(DataRow row)

    {

        this.row = row;

    }



    public object this[string name]

    {

        get { return row[name]; }

    }

}

I think if I were designing a data layer that used plain ADO.NET (which I would never do), I would use this simplified interface. Of course, the drawback is there would be a need to adapt both IDataReaders and DataRows when passing them to consuming methods, whereas only DataRows would need to be adapted when consuming methods are programmed to the IDataRecord interface.

I Like to Make Judgments About Things I Am Far from Qualified to Judge

2009-04-17T11:18:00.001-05:00

I’ve read a few posts about Kobe, a new sample ASP.NET MVC application intended to provide guidance for web application development. One thing that really jumps out at me (taking the bloggers at their word) as a glaring mistake is the absence of any unit tests. I mean, isn't testing one of the driving factors for the creation of ASP.NET MVC (second bullet point)?

Rhino Mocks Caveat: Expect.Call / Setup.For / Stubs and Defaults

2009-04-15T17:47:00.001-05:00

I got bitten by not knowing some Rhino Mocks API details today. I had some tests written a certain way which were passing and some others written the same way which were failing. (Code can be found here.) In the case of the successful tests, Rhino Mocks appeared to be properly returning a mock object when a property was called on another mock, and in the case of the failing tests it was returning nulls for the property on a mocked object. There didn’t appear to be any difference in the way I needed to declare and setup the mocks used in the test, but there was a subtle one: the code that passed the tests only accessed the property once, whereas the code that failed accessed it multiple times. Because of the way I set up my mocks, a mock was returned for the property the first time it was accessed only.

If you use Expect.Call(…).Return(someObject), by default the method/property will only return the specified object once. If you use a stub or SetupResult.For(…).Return(someObject), by default the method/property will return the specified object as many times as it is called.

Since I prefer the consistency of using Expect.Call for any kind of expectation (and I think it reads better), I used Expect.Call(…).Return(someObject).Repeat.Any() to allow the property to return what I wanted every time it was called.

File this under the importance of defaults.

Strongly-Typed Property Constraints in Rhino Mocks

2009-04-11T20:42:00.002-05:00

UPDATE: As I suspected, this functionality was right in front of my face – it’s called PredicateConstraint in Rhino Mocks. I also realize that I managed to completely ignore the existence of Predicate<T> in the framework, and write my own predicate delegate. Hey, I was on a roll.

Rhino Mocks has a PropertyConstraint class that allows you to check the values on properties of objects passed into the method as part of the verification for that method being called. Unfortunately, the name of the property is specified as a string, which means the benefits of strong-typing that Rhino Mocks is normally so good at preserving are lost. Here’s an example (using Rhino Mocks 3.3 and .NET 2.0):

[Test]

public void Main_Form_Should_Show_Start_Panel_On_Load()

{

    MockRepository mockRepository = new MockRepository();

    IMainFormView mockView = mockRepository.DynamicMock<IMainFormView>();



    IEventRaiser loadEventRaiser = GetEventRaiserFor(delegate { mockView.Load += null; });

    Expect.Call(

        delegate

        {

            mockView.SetMainFormControlVisibility(null);

        }).Constraints(new PropertyConstraint("StartPanelIsVisible", Is.Equal(true)));

    mockRepository.ReplayAll();



    IMainFormController controllerUnderTest = new MainFormController(mockView);

    loadEventRaiser.Raise(mockView, EventArgs.Empty);



    mockRepository.VerifyAll();            

}

Basically, the view’s method SetMainFormControlVisibility takes an object with a property called StartPanelIsVisible. We want to make sure that when the controller calls this method, this property is set to true on the parameter object. In fact, that is the sole reason for the existence of this test. Using a string to specify the property name isn’t very conducive to refactoring, and it would be nice to have intellisense and compile-time argument checking available when we specify the constraints for an object’s state. I found myself writing this class:

public class PropertyConstraint<T> : AbstractConstraint where T : class

{

    public delegate bool ConfirmPropertyState<U>(U statefulObject);

    private readonly ConfirmPropertyState<T> confirmPropertiesMatch;



    public PropertyConstraint(ConfirmPropertyState<T> confirmPropertiesMatch)

    {

        this.confirmPropertiesMatch = confirmPropertiesMatch;

    }



    public override bool Eval(object obj)

    {

        AssertObjectIsCorrectType(obj);

        T objectToConfirmStateOf = Cast(obj);



        return confirmPropertiesMatch(objectToConfirmStateOf);

    }



    public override string Message

    {

        get { return String.Format(

            "The properties of the passed in {0} do not match the expectations of the constraint.", 

            typeof(T).FullName); }

    }



    private static void AssertObjectIsCorrectType(object obj)

    {

        if (!(obj is T))

        {

            throw new ArgumentException(

                String.Format(

                    "PropertyConstraint expected to evaluate an object of type {0} but was pass an object of type {1}",

                    typeof (T).FullName,

                    obj.GetType().FullName));

        }

    }



    private static T Cast(object obj)

    {

        return obj as T;

    }

}

Which changes our test to look like this:

[Test]

public void Main_Form_Should_Show_Start_Panel_On_Load()

{

    MockRepository mockRepository = new MockRepository();

    IMainFormView mockView = mockRepository.DynamicMock<IMainFormView>();



    IEventRaiser loadEventRaiser = GetEventRaiserFor(delegate { mockView.Load += null; });

    PropertyConstraint<MainFormControlVisibility> startPanelIsVisible = 

        new PropertyConstraint<MainFormControlVisibility>(

            delegate(MainFormControlVisibility match) 

            {

                return match.StartPanelIsVisible; 

            });

    Expect.Call(

        delegate

        {

            mockView.SetMainFormControlVisibility(null);

        }).Constraints(startPanelIsVisible);

    mockRepository.ReplayAll();



    IMainFormController controllerUnderTest = new MainFormController(mockView);

    loadEventRaiser.Raise(mockView, EventArgs.Empty);



    mockRepository.VerifyAll();

}

I admit this is pretty clunky (it looks better with lambdas), but it achieves the object of getting rid of the string for property specification.

I’m almost sure something like this exists in Rhino Mocks as it is, but I couldn’t find it, so I thought I’d share this. Again, I’m using an older version of Rhino Mocks (3.3).

The Misadventures of a .NET Dev

2009-04-10T22:56:00.001-05:00

Sooo... long time, no post! All zero readers of this blog might be curious about why I disappeared. The short story is I’ve been sidetracked by personal issues combined with a butt-ton (sorry to those in far away lands; I don’t know how to convert this to metric) of work at my paying gig. We’ve all been there and done that. I’m sure you can relate, non-existent reader. But I’m not making any more excuses! This post serves as a list of topics I want to cover in future posts. It’s long, so I doubt I’ll get to all of these.

More ‘SharpMock’ – I haven’t abandoned this project, but I was saddened when I realized I had forgotten all I learned about PostSharp when I cracked open the [smelly from having gone so long without bathing] spike code.
Creating DSLs with MGrammar – I’ve noticed a lot of bloggers are unsure about the vision Microsoft has for ‘Oslo’. Count me among them. But I definitely have had some fun playing around with Intellipad and MGrammar recently. I see a lot of potential for making my development life easier when it comes to maintaining metadata. I also have an idea for a little project to make it easier to author certain scripts that perform a certain development function which currently depend on some ugly XML (I’m awesome at starting projects and terrible at finishing them).
ASP.NET WebForms and the MVP Pattern: What Not to Do – I wish I had time to even play the the new (or old for that matter) MVC bits. I wish I had time to learn Silverlight 3 (or 2, or 1 for that matter). I wish I had time to use jQuery (or some other cool JS framework for that matter) and improve my piss poor JavaScript skills. Alas, we’re stuck in the stone age of web development at my job. I’ve done my best to reduce code duplication and improve testability with the MVP pattern, and along the way I’ve done a lot of stupid things that I think others should avoid. Actually, I probably shouldn’t write about MVP at all. Meh.
Persisting Abstract Expression Trees: What Not to Do – Again, the stone age (hmm, I should probably be capitalizing that) of development means not using an ORM. I have some advice about what to avoid if you have to persist expression trees and write all of the data access code. This will mainly be about persisting inheritance hierarchies (table per class, table per subclass, etc.) and coping with object model changes.
Building a LINQ Provider – I have no idea why, but I want to do this. I’m specifically thinking of a fun little project called either ‘LINQ to MP3’ or ‘LINQ to ID3’ (I’m good at naming things and horrible and building them). I figure it’s time to start learning .NET 3.5 since .NET 4.0 will be out sometime soon. On that note…
.NET Certification Fun! – I never got any MS development certifications (I did manage to fail one test… seriously), and I’ve listed getting my MCPD as a goal at work. I have some opinions on the certifications in general, and occasionally I run across interesting things in the process of studying (okay, I don’t study). I’ll blog about this. P.S. We’re talking .NET 2.0 here :(
Ruby, Ruby, Rubyyyyy – I’m not talking about a Kaiser Chiefs song. I’ve been playing around with Ruby a little (and reading Why's (Poignant) Guide to Ruby, which is absolutely hilarious), and it’s a lot of fun. I actually probably won’t blog about this, as I don’t have much to say.

Well, that’s all I can think of for now. Talk to you again in 6 months!

Hello, PostCompiler World!

2008-11-09T14:53:00.001-06:00

Sometimes doing the simplest things is difficult. In order to make any headway on SharpMock, I’ll need to be able to understand the basics of PostSharp. What could be more basic than getting PostSharp to execute a task that ouputs a ‘Hello World’ message during the postcompilation process? We’re not decorating any types with attributes; we’re not intercepting any calls; we’re not outputting any IL. This should be a snap! And yet, I haven’t posted in weeks….

First thing’s first – we need a ‘Hello World’ task. In a project called PostSharpPlugin I have defined the following class:

using PostSharp.Extensibility;

namespace PostSharpPlugin
{
    public class SayHelloTask : Task
    {
        public override bool Execute()
        {
            Console.WriteLine("Hello, PostCompiler!");

            // Task executed successfully
            return true;
        }
    }
}

I have also created a .psplugin file that looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<PlugIn xmlns="http://schemas.postsharp.org/1.0/configuration">
  <TaskType Name="SayHello" Implementation="PostSharpPlugin.SayHelloTask, PostSharpPlugin" Phase="Analyze">
  </TaskType>
</PlugIn>

So, there we have a plugin that will perform some tasks during postcompilation. We want this task to be performed during postcompilation of some other assembly if it references this plugin, so we need some way to tell PostSharp about this requirement. To do so, we add an attribute to PostSharpPlugin:

[assembly: ReferencingAssembliesRequirePostSharp("SayHello", "PostSharpPlugin")]

I have created another assembly called (very cleverly) ReferencingAssembly and added a reference to PostSharpPlugin. That assembly contains this .psproj file:

<Project xmlns="http://schemas.postsharp.org/1.0/configuration" ReferenceDirectory="{$ReferenceDirectory}">
  <SearchPath Directory="{$SearchPath}" />
  <Using PlugInFile="../PostSharpPlugin/bin/Debug/PostSharpPlugin.psplugin" />
  <Tasks>
    <AutoDetect />
    <SayHello />
    <Compile TargetFile="{$Output}"
     IntermediateDirectory="{$IntermediateDirectory}"
     CleanIntermediate="{$CleanIntermediate}"
     SignAssembly="{$SignAssembly}"
     PrivateKeyLocation="{$PrivateKeyLocation}"/>
  </Tasks>
</Project>

The Using element tells PostSharp where to get the definition for the task SayHello. This is critical. I spent every spare hour I had for weeks trying to get this seemingly simple example to work without defining or importing the definition of the SayHello task in this file. In fact, I don’t think I should have to explicitly specify the SayHello task to be executed here either. All the tracing, debugging, and specifying different search paths I could do didn’t help me get this example working, so for now importing the task definition like so is the solution I’m rolling with. It will allow us to make some headway, like figuring out how to check a test assembly for methods that need to be mocked. Ultimately, though, we’ll need PostSharp to automatically detect and use tasks that provide services like ICustomAttributeProvider, and this solution won’t handle that.

Oh, by the way, don’t forget that we need to invoke PostSharp when we compile our assembly. For that we need to import the PostSharp MSBuild task. The modified ReferencingAssembly.csproj file for this example looks like this at the end (the second element is what has been added):

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
  <Import Project="..\ThirdParty\PostSharp.targets" />

I have uploaded the code for this example here. I have included all of the needed PostSharp files in the ThirdParty directory. (I’m not sure this distribution is allowed.) So, it should “just work”… you can open the solution in Visual Studio, build, and see something like this in the build output window:

...
PostSharp 1.0 [1.0.11.424] - Copyright (c) Gael Fraiteur, 2005-2008.

Hello, PostCompiler!
...

Misindirection

2008-10-17T00:12:00.004-05:00

The first time I popped open the solution after I did my ‘SharpMock’ spike, I was met with a surprise – the one test was failing! Surely I didn’t commit a cardinal sin and write a post about something that didn’t even work. It turns out I had been messing around with the OnMethodInvocationAspectOptions returned by overriding the GetOptions method of OnMethodInvocationAspect. Here’s the code that was in MockableAttribute:

public override OnMethodInvocationAspectOptions GetOptions()
{
    return OnMethodInvocationAspectOptions.WeaveSiteCall;
}

The original incarnation of Expect.Call(….) took a string to specify which method on which class to call, so the test passed with the above code. Now we have this syntax:

Expect.Call(() => PersonDao.GetPerson(0), ryan);

And the test doesn't pass. This means that if we want to have syntax like this (and we do!), we have to do the weaving in the class we’re calling. Much more importantly, if we want to preserve this syntax and not modify the called class (and in the future we will!), we’ll have to intercept calls made in the test as well.

One Post Wonder?

2008-10-17T00:12:00.001-05:00

I figured the first hurdle to tackle in proving that we can use PostSharp to bend assemblies to our unit testing wills was to get rid of the need to decorate the targets of our mocking desires with attributes. I spent some time going over the documentation, browsing the forums, and looking through samples. Gael pretty much told me in the comments to my previous post to look into ICustomAttributeProvider and CompoundAttribute. I tried and failed to implement ICustomAttributeProvider; I think I don't quite understand how a PS plugin works yet. I thought going through Ruurd Boeke's examples would be enlightening... no such luck. So, instead of doing the smart thing and actually asking for help, I'm going to continue to waste time trying to figure it out on my own.

Eventually I'll get fed up and ask for some help, but in the meantime I need to make some progress somewhere in this experiment. I might as well take what I have done and at least build out some real functionality. This brings up a whole slew of interesting decisions I need to make:

How should I structure the solution? I'm going to put any serious decisions this off until I gain better understanding of the way PS works, the licensing issues, what it is I actually want to accomplish, whether or not it's feasible, etc. I'm making a note now that the structure of the solution is going to drastically change.
What should the API look like? Do I support multiple models for constructing unit tests (Arrange/Act/Assert and/or Record/Replay)? How do I initialize the mocks? What threading considerations do I need to make?
How do I test? I plan on using TDD, but testing a framework used for testing seems to throw me into some sort of backwards meta-testing scenario that just feels weird.

Since I can't clearly explain it, I probably need to illustrate what I mean by that last point.

As it stands right now in my very simple implementation, the data about the calls that need to be faked, their arguments, and the faked return values are stored in static fields of the Expect class. In order for tests to be atomic, independent units, these fields need to be reset for each test. The requirement is simple, but how do we write an individual test to test this functionality? I don’t know either. What I ended up with was this:

[Test]
public void Will_Get_Person_From_Mocked_Call()
{
    var ryan = new Person { Id = 11, Name = "Ryan" };

    // Set the expectation for the dao call
    Expect.Call(() => PersonDao.GetPerson(0), ryan);

    // Note that we don't care about the person id argument
    var commandUnderTest = new PersonGetCommand();
    var resultingPerson = commandUnderTest.Execute();

    Assert.That(resultingPerson == ryan);
}

[Test]
public void Wont_Get_Person_From_Mocked_Call()
{
    var commandUnderTest = new PersonGetCommand();
    var resultingPerson = commandUnderTest.Execute();

    Assert.That(resultingPerson.Id != 11);
}

These two tests work together to signal whether or not the Expectations are being correctly discarded at the end of a test/before the next test. If the second test fails, they aren’t. So I started with this, wrote some crappy code in the Expect class, and ended up adding these setup and teardown methods to the TestFixture:

[SetUp]
public void InitializeMockFramework()
{
    Expect.Initialize();
}

[TearDown]
public void UnloadMockFramework()
{
    Expect.UnLoad();
}

Don’t panic… I know this is ugly, especially considering what must be on the other side of Initialize and UnLoad, but this is strictly to illustrate a point – the whole fixture together functions as a single unit. Not ideal, but it’s the best solution I can come up with at the moment to test testing. It allows me to refactor the Expect class and verify that I haven’t broken functionality.

(Side thought: I’m thinking I should take a second look at that XUnit Test Patterns book; I labeled it ‘boring’ the first time I skimmed through it.)

Stubbing Static Methods with PostSharp

2008-10-12T14:29:00.001-05:00

TypeMock uses the Profiler API to allow mocking, stubbing, etc. of classes used by code under test. It has the ability to handle sealed classes, static classes, non-virtual methods, and other troublesome-yet-oft-encountered scenarios in the world of unit testing. Other frameworks rely on proxies to intercept method calls, limiting them to be able to only fake virtual, abstract, and interface members. They also rely on dependecy injection to place the proxies as the concrete implementation of calls to the abstracted interface members.

Anyone working with a legacy codebase is bound to run into static method calls (especially in the data access layer), dependencies on concrete types with non-virtual methods, and sealed class dependencies (HttpContext anyone?). The only way to unit test this without refactoring is with TypeMock. I've never used TypeMock, and I'm sure it's a great product, but it's not free. I decided to spike some code to see if I could solve the problem of mocking static method calls through AOP with PostSharp. What I came up with was a pretty ugly solution with limited applicability that will probably help no one. Let's take a look!

The example codebase is trivial: we have a PersonGetCommand representing the business logic we want to test and a PersonDao class with a static GetPerson method representing a method we want to stub. GetPerson returns, you guessed it, a Person.

To intercept calls to the static method, we're going to place a MockableAttribute on the method. It looks like this:


[Mockable]
public static Person GetPerson(int personId)
{
    return new Person { Id = personId, Name = String.Format("Person {0}", personId) };
}

The code for the attribute talks to our 'mock framework'. It looks like this:


[Serializable]
public class MockableAttribute : OnMethodInvocationAspect
{
    public override void OnInvocation(MethodInvocationEventArgs eventArgs)
    {
        MethodInfo invokedMethod = eventArgs.Delegate.Method;

        // If this gets called during recording, we have to register the expectations
        if (Expect.IsInRecordMode)
        {
            Expect.RegisterExpectedCall(invokedMethod);
            Expect.RegisterExpectedArguments(invokedMethod, eventArgs.GetArgumentArray());
            Expect.RegisterExpectedReturnValue(invokedMethod, Expect.CurrentlyExpectedReturnValue);
        }
        // If not, we need to check to see if we're mocking the method
        else
        {
            // If it is mocked, we intercept the call
            if (Expect.MethodIsMocked(invokedMethod))
            {
                eventArgs.ReturnValue = Expect.GetExpectedReturnValue(invokedMethod);
            }
            // Otherwise, we invoke the method
            else
            {
                eventArgs.ReturnValue = eventArgs.Delegate.Method.Invoke(eventArgs.Delegate.Target, eventArgs.GetArgumentArray());
            }
        }
    }
}

To prove that the example codebase works correctly, we have this test:


[Test]
public void Will_Get_Person()
{
    var expectedName = "Person 23";
    var personId = 23;

    var commandUnderTest = new PersonGetCommand { PersonId = personId };
    var resultingPerson = commandUnderTest.Execute();

    Assert.That(resultingPerson.Name == expectedName);
    Assert.That(resultingPerson.Id == personId);
}

And this test shows our MockableAttribute (as well as our makeshift mock framework) in action:


[Test]
public void Will_Get_Person_From_Mocked_Call()
{
    var ryan = new Person { Id = 11, Name = "Ryan" };

    // Set the expectation for the dao call
    Expect.Call(delegate { PersonDao.GetPerson(0); }, ryan);

    // Note that we don't care about the person id argument
    var commandUnderTest = new PersonGetCommand();
    var resultingPerson = commandUnderTest.Execute();

    Assert.That(resultingPerson == ryan);       
}

Note that I chose a Rhino-like syntax for the expecations. Also note that we aren't really 'mocking' the call because we aren't verifying expectations or arguments. This could easily be done, however.

This is all dreadfully simple thanks to PostSharp. But is this approach ready for primetime? It's far from it, in fact, and here are the reasons:

It only works for classes you control (and currently only for static methods). So if you're making a call to a static method in a third-party dll or a .NET framework class, this is useless.

Requires the use of an attribute. It may only be metadata, but testing concerns shouldn't be leaking into application source.

It modifies that actual assemblies being tested. Technically, this approach tests only a modified-for-test assembly, not the assembly that we want to release into production.

The assembly under test requires a reference to PostSharp.Public.dll and PostSharp.Laos.dll.

Performance could be poor. Code weaving adds overhead to the compilation process. Tests and the code they test are frequently compiled.

~~PostSharp is tied to MSBuild. NAnt tasks running on a build server might not be able to execute tests using this mock framework.~~ (See comments to this post from PostSharp creator Gael Fraiteur.)

A bunch of other things I forgot.

Some of these concerns can be alleviated, and some cannot. I would like to prove this out soon (though I doubt I'll be able to):

Interception can be done at the call site without modifying the called assembly.

The code weaver can be provided with interception points (join points? advice points? I don't understand AOP terminology at all) without them being marked with attributes. This has to be true if we want to do (1) anyway. Unfortunately, it's not going to be easy (otherwise Laos would probably already do it).

Nothing can be done about modifying the assemblies being tested; that's the whole point. We're weaving code to achieve interception.

~~Nothing can be done about referencing PostSharp. Again, that's the point.~~ Gael corrected me on this. We'll tackle this in the distant future.

Overhead per-compilation isn't too bad. It's better than overhead per-test.

There are ways to invoke PostSharp from the command line~~, so NAnt tasks the coupling to MSBuild can be overcome~~ (Deleted not only for being obvious typo nonsense but also because Gael points out that there is already a NAnt task for PS 1.5). I don't really care about this right now (still true anyway).

I sometimes remember things I previously forgot.

If anyone ever reads this post and is interested, I will find a way to provide the solution I used to spike this.

(Side thought: I wonder, if I were to start an open source project called 'SharpMock' as an alternative TypeMock, could I get a free version of TypeMock to aid in its development?)

Who I'm Is

2008-04-20T22:36:00.000-05:00

I am a junior .NET developer currently working in Chicago, IL. I am starting this blog in order to enhance my knowledge of programming subject matter. Hopefully, someone else will be helped along the way. This first post will probably be edited soon...