PostSharp is an AOP framework that works using byte code weaving. That is, it re-writes your IL to add behaviors to it. From my point of view, it is like having the cake (interception, byte code weaving) and eating it (I haven't even looked at the PostSharp source code, just used the binary release).

My initial spike with it went very well. Here it is:

[Serializable]
public class Logger : OnFieldAccessAspect
{
    public override void OnGetValue(FieldAccessEventArgs eventArgs)
    {
        Console.WriteLine(eventArgs.InstanceTag);
        Console.WriteLine("get value");
        base.OnGetValue(eventArgs);
    }

    public override InstanceTagRequest GetInstanceTagRequest()
    {
        return new InstanceTagRequest("logger", new Guid("4f8a4963-82bf-4d32-8775-42cc3cd119bd"), false);
    }

    public override void OnSetValue(FieldAccessEventArgs eventArgs)
    {
        int i = (int?)eventArgs.InstanceTag ?? 0;
        eventArgs.InstanceTag = i + 1;
        Console.WriteLine("set value");
        base.OnSetValue(eventArgs);
    }
}

This is an aspect that run on each field access. It is not really useful, but it helps to show how things works. A couple of things that are I think are insanely useful:

• Aspects are instantiated at compile time, allowed time to set themselves up, then serialized to an resource in the assembly. At runtime, they are de-serialized and ready to run. The possibilities this give you are amazing.
• InstanceTag is a way to keep additional data per aspect.

Now, let us assume that I want to add the aspect to this code:

[Logger]
public class Customer
{
    public string Name { get; set; }
}

Note, there is no field. (Well, there is, it is generated by the compiler). Now we compile and run the PostSharp post compile step. With that, we can now investigate what is going on.

As you can see, we are deserializing the attribute and storing it in a field that we can now access. Let us check the Customer implementation now:

We have the logger field, which is used for something, but we also have the ~get~<Name>k__Backingfield and ~set~<Name>k__BackingField. <Name>k__BackingField (and I would love to hear the story behind that) is the compiler generated field that was created for us. The ~get~... and ~set~ are generated by PostSharp. Before we look at them, we will look at the implementation of Name.

Where it used to call the field directly, now it is doing this via a method call. And now we can look at those method calls.

There is a lot going on here. We create a new field access event arg, call the aspect method, and return the value. Note that the state (instance tag) is stored in the object as well, for each field access.

It looks very well done.

This post is derived from the Rhino Mocks 3.5 documentation.

Setting expectations for property set was always very simple, and slightly confusing with Rhino Mocks. Here is how you do it:

view.Username = "the user name";	

The problem is that it is hard to see that there is an expectation created here. So, with the generous help of Sebastian Jancke, we have a new syntax:

Expect.Call(view.Username).SetPropertyWithArguments("the user name");

This is much more explicit and easier to understand. We can also set expectation on the property set, without expecting a certain value using this syntax:

Expect.Call(view.Username).SetPropertyAndIgnoreArguments();

I am currently working (well, sort of, more playing around) on the NHibernate Profiler. I thought that this would be a good time to describe how I approach most development tasks.

I don't actually have the time/strength to start serious development effort, but I have the time to do a lot of spikes, and to think about architecture. If I decide to spend the time making this happen, I'll post more about how it works.

I started with a spike about extracting the actual data from NHibernate. My target goal is being able to profile NHibernate 2.0 without having to modify NHibernate to support this. I actually run into some issues with that, more specifically, I run into technical issues with my chosen approach. Instead of spending time on troubling shooting that, I chose another path. That may not be the way it will end, but I am not interested in the technicalities at the moment, I am interested in the feasibility of the project. Suffice to say that I was successful (and learned a bit about named pipes :-) ).

Next, SQL formatting is a pain, but it is something that is mandatory for a profiler, a least if you want to let the users a fighting chance in understanding what is going on. I found a solution for that as well, which I am extremely pleased with.

Next is not the actual application architecture, but the user interface. That helps nailing down what the application is going to do, and cement what it is going to do. I am also a great believer of building from the top down, and the architecture that I have in mind make it very simple to split back end processing from the front end.

This is an example of what I have in mind. This is concept UI. It is not meant to be the final thing, it is here merely to give me an idea about what I am going to build. This UI was generated with the assistance of power point and paint, the disclaimer is what I usually put whenever I create a UI.

What you can't see, and the purpose of the UI building exercise, is the mental model that it helped me create (the main concepts in the application are sessions, statements and warnings/suggestions). There is a streaming rule set that process those, and a whole set of functionality that just sits there in my head.

The next step, at this point, is getting from a UI sketch to a working UI draft. What do I mean by that? It means building the UI (which will intentionally look ugly) and hooking it to a dummy back end. The reasoning here is quite simple. I don't care for the look and feel at the moment, that is utterly uninteresting to me at this point, because I have seen what real UI developers can do, and I am not in their league so I am not going to even try.

What I do care about in this stage is the actual operation of the UI. I can hand it over for the professionals to handle the beautification process after that part work. Of course, I feel bad about not knowing more about this, so I may spend more time there than I should, but I am going to try.

After the presentation layer is done, we can start focusing on the actual back end. That is going to composed of event processing pipeline with a set of rules that I can use to provide warnings and suggestions about what to do. Still debating the interaction between the back end and the front end. Most likely this is going to be a simple ThreadSafeQueue<T> and that's it.

Oh, and here is the total sum of code written so far:

And if you think that this is interesting that I am not showing code, you are right, what is see is what is :-)

The easiest way of getting there is to have no mutable state. And here is a simple test to ensure that. Seeing how CouchDB code works and how erlag handle things is quite educating in this regard.

[TestFixture]
public class EnssureTypesSafeForMultiThreadingTestFixture
{
    [Test]
    public void TypeIsSafeForMultiThreading()
    {
        var visitedTypes = new List<Type>
        {   // immutable types, partial list
            typeof(int),
            typeof(long),
            typeof(string),
            typeof(DateTime)
        };
        foreach (var type in GetRootTypesToCheck())
        {
            CheckType(type, visitedTypes);
        }
    }

    private static void CheckType(Type type, ICollection<Type> types)
    {
        if(types.Contains(type))
            return;
        types.Add(type);
        var fields = type.GetFields(BindingFlags.Instance|BindingFlags.NonPublic|BindingFlags.Public);
        foreach (var info in fields)
        {
            var isReadOnlyField = (info.Attributes & FieldAttributes.InitOnly)==FieldAttributes.InitOnly;
            if(isReadOnlyField==false)
                throw new InvalidAsynchronousStateException("Dude, " + type + "." + info.Name +
                                                            " is not marked as read only. You are NOT safe for multi threading, enjoy the deadlock, bye!");
            CheckType(info.FieldType, types);
        }
    }

    private static IEnumerable<Type> GetRootTypesToCheck()
    {
        // return types that I am interested in verifying
    }
}