THIS BLOG HAS MOVED – Please Update your RSS Subscription

image

 

The feed url is: http://feeds.feedburner.com/TheFreakParade

The home page is: http://thefreakparade.com/

The about page is: http://thefreakparade.com/about/

I sort of stole the dev team blog for my own glory, so I’m returning hsidev.wordpress.com to the team for internal discussions and moving my illicit activities to a permanent home. All existing posts will be updated and maintained on the new blog, and of course all new content will move to that location as well. Hope to see you there.

Advertisements

Another Free E-Book – Domain Driven Design Quickly

Yet another community gift – this time an e-book about Domain Driven Design. You can buy a print version but the PDF is free, and small enough to easily print out yourself and bind with a clip. The book is by the founder and editor of InfoQ.com, and is billed as a summary of Eric Evans (this one, not this one ) famous book, Domain Driven Designimage At this rate I may never have to purchase another book again.

Foundations of Programming – free ALT.NET e-book

I am constantly amazed (and humbled) by the generosity of time experts in this field of very, very busy people continue to demonstrate over and over again. I don’t know if other professions are the same way, but it really makes this one a pleasure to work in. Here is a free e-book by Karl Seguin of CodeBetter.com. I haven’t read it yet, but I very much look forward to it. From the TOC it looks like it will be a very useful resource.

You can get it here.

image

Baby Stepping into MSIL – creating an "Event Recorder" using a DynamicMethod and Reflection.Emit

I’ve often been caught between two opposing forces – the desire to find some excuse to use Reflection.Emit to dynamically generate behavior, because it has a sort of magical quality about it, and on the other hand being completely intimidated by the strange and foreboding mysteries of IL. I finally found an excuse compelling enough to brave my fears and stick my toe in the water, and it wasn’t too bad.

The excuse to take the plunge was, as is often the case, laziness (or perhaps impatience). I had an interface with a blue million events on it, and I wanted create some unit tests that ensured all my little events were fired the right number of times, in the right order, with the right arguments, but I didn’t want to subscribe to all the events individually and set a bunch of flags, etc. etc. (BTW – I imagine this problem has been solved by superior minds – I didn’t spend much time looking)

[UPDATE] Here is a CodeProject article explaining how to do essentially the same thing as EventRecorder without using Reflection.Emit. Instead, an EventProxy intermediary class is used to store the EventName. http://www.codeproject.com/KB/cs/eventtracingviareflection.aspx 

The sample code, along with unit tests and a Windows Forms app demonstrating possible usage, can be found here.

Here is a typical usage:

[Test]
public void Recorder_Will_Record_Events()
{
    var source = new TestEventSource();
    using (var recorder = new EventRecorder(source))
    {
      source.FireSimpleEvent();
      source.FireSimpleEvent();
      source.FireEventWithCustomArgs("MyTestText");
      source.FireSimpleEvent();
      source.FireEventWithCustomArgs("NewTestText");

      Assert.That(recorder.EventHistory.Length, Is.EqualTo(5));

      Assert.That(((TestEventArgs) recorder.EventHistory[2].Args).LoveMe, Is.EqualTo("MyTestText"));
      Assert.That(((TestEventArgs) recorder.EventHistory[4].Args).LoveMe, Is.EqualTo("NewTestText"));

      Assert.That(recorder.GetInvocationsFor("SimpleEvent").Length, Is.EqualTo(3));
      Assert.That(recorder.GetInvocationsFor("EventWithCustomargs").Length, Is.EqualTo(2));
     }
}

What I wanted to do was “record” all the events that were fired on a particular object during the course of some transaction, and then test that all the events that fired were the ones I was expecting, and in the appropriate order. I figured I would achieve this by creating a class called EventRecorder that could take in its constructor any other non-null object. It would then loop through each event in the objects type, subscribe to that event, and when the event fired add the name of the event and the EventArgs to a collection I could examine later. Pretty simple.

I though this would be a simple matter of using some plain ol’ reflection, like this:

 foreach (EventInfo evt in eventSource.GetType().GetEvents())
 {
 	evt.AddEventHandler(eventSource,
            new EventHandler(
		(sender,args)=>RecordEvent(evt.Name,args)));
 }

 

But alas, AddEventHandler expects a delegate that exactly matches the signature of the event, meaning if I have an event defined with EventHandler<CancelEventArgs>, it isn’t going to let me pass a plain EventHandler delegate. So what to do? Dynamically generate an event handler with the appropriate signature, of course, and emit a simple call to my RecordMethod. Essentially, we’ll be generating the equivalent of this:

private void HandleEvent(object sender,EventArgs<CancelEventArgs> args)
{
    this.RecordEvent(args,"NameOfTheEvent");
}

I found an MSDN article that looked like just the ticket. The technique presented uses the DynamicMethod class, which you can use to create an ad hoc method and fill it full of op-codes to tell it what to do. In this case, we wanted to instantiate a DynamicMethod that matches the signature of the event handler we want to subscribe to. Then we simply needed to emit the IL to call the RecordEvent method and pass in the appropriate arguments. In the code below, EventSource refers to the object whose events we’re subscribing to, and was passed in to the constructor of the EventRecorder class.

/// <summary>
/// This method crates a DynamicMethod matching the signature of
/// the delegate required by the passed in EventInfo. The method
/// will simply pass the arguments on to the RecordEvent method.
/// </summary>
/// <param name="evt"></param>
protected void BindToEvent(EventInfo evt)
{
    Type handlerType = evt.EventHandlerType;

    if (handlerType == null)
        throw new ArgumentException("No handler could be " + 
                              " identified for " + evt.Name);

    Type[] handlerParams = GetDelegateParameterTypes(handlerType);

    //Not technically required, but may be helpful if an exception is thrown
    String dynamicHandlerName = 
        String.Format("EventSource_{0}", evt.Name);

    var handlerDef = new DynamicMethod(dynamicHandlerName,
                                       typeof(void),
                                       handlerParams,
                                       typeof (EventRecorder));


    MethodInfo recordEvent =
        typeof (EventRecorder).GetMethod(
            "RecordEvent",
             BindingFlags.Instance | BindingFlags.NonPublic);

    ILGenerator ilgen = handlerDef.GetILGenerator();
    
    //load 'this' onto the stack
    ilgen.Emit(OpCodes.Ldarg_0);

    //load the second argument (EventArgs) onto the stack
    //We're not using the sender parameterf of the delegate,
    //so we skip emitting OpCodes.Ldarg_1
    ilgen.Emit(OpCodes.Ldarg_2);

    //Load the name of the event onto the stack
    ilgen.Emit(OpCodes.Ldstr, evt.Name);

    //Call the RecordEvent method, passing the two loaded argumetns
    //EventArgs args and String name
    ilgen.Emit(OpCodes.Callvirt, recordEvent);

    //Return control
    ilgen.Emit(OpCodes.Ret);

    //Create a delegate out of this new handler, binding to the current
    //instance as the target
    Delegate handler = handlerDef.CreateDelegate(handlerType,this);

    try
    {
        //Register the new delegeate with the event on the event source
        evt.AddEventHandler(EventSource, handler);
    }
    catch (Exception ex)
    {
        //Some COM objects don't like this method. In production, you wouldn't
        //eat this error like this, but for my example, I wanted to show events
        //on the WebBrowser control, and certain events of WebBrowser
        //don't appreciate this dynamic approach. So...
    }

    //record this handler so we can get to it later
    //when we need to remove our registration from 
    //the event source during dispose
    _handlers.Add(evt.Name, new EventRef(handler,evt));
}

/// <summary>
/// Extract the signature of the event's delegate
/// </summary>
/// <param name="d"></param>
/// <returns></returns>
private static Type[] GetDelegateParameterTypes(Type d)
{
    if (d.BaseType != typeof (MulticastDelegate))
        throw new ApplicationException(
            d.Name + " is not a delegate.");

    
    MethodInfo invoke = d.GetMethod("Invoke");
    
    ParameterInfo[] parameters = invoke.GetParameters();
    
    //Allocate an extra slot, see below for why
    var typeParameters = new Type[parameters.Length+1];
    
    for (int i = 0; i < parameters.Length; i++)
    {
        typeParameters[i+1] = parameters[i].ParameterType;
    }

    //This is an extremely important step - we need to inject the type
    //of EventRecorder because we will be using EventRecorder as the Target
    //of the dynamic delegate that we create using the DynamicMethod. When
    //you go to convert your emitted MSIL to an actual delegate using DynamicMethod.CreateDelegate,
    //the first argument of the signature MUST match the target object you are binding
    //the delegate to. 
    typeParameters[0] = typeof (EventRecorder);

    return typeParameters;
}

/// <summary>
/// The internal method that gets called by the dynamically
/// generated delegates we are using to bind to the EventSource's
/// events. This method will get called once for every event that fires
/// on the EventSource.
/// </summary>
/// <param name="args"></param>
/// <param name="eventName"></param>
protected virtual void RecordEvent(EventArgs args, string eventName)
{
    EventInfo evt = _handlers[eventName].Event;

    if (evt != null)
    {
        var history = new EventInvocation { Args = args, Event = evt };
        _eventHistory.Add(history);
        OnEventRecorded(history);
    }
}

 

IL is pretty close to the machine, relative to C#, so it’s entirely stack based. You load arguments onto the call stack, then perform an operation, such as calling a method. If you call a method, and the method has a signature with arguments, the arguments for the method signature are popped off the stack and consumed.

In this example we’re generating a dynamic method with a signature of two visible arguments – (object,MyEventArgs) – but we’re calling a method (RecordEvent) with a slightly different signature (EventArgs,string). We can discard the “object” argument of the dynamic method, which we do simply by not loading it onto the stack, which is why we don’t emit the opcode Ldarg_1, but we need to load the EventArgs and a string.

Looking at my source code it doesn’t quite add up though, because you can see I’m loading argument 0 (Ldarg_0) which looks like it should be “object” based on the dynamic method signature and argument 2 (Ldarg_2) which doesn’t even seem like it should exist, as the signature is (object,EventArgs) – only two arguments. Well, it turns out that all instance methods require a 0 position argument that is “this” – this argument is inserted by the compiler so you never see it, but when you say “this.DoSomething()” in your code, in IL method signature that gets created is DoSomething(MyType this). That means our call to “RecordEvent(EventArgs,string)” really looks like this: “RecordEvent(EventRecorder,EventArgs,string)”, which means we need to load 3 variables onto the stack, which we do:

Ldarg_0 = this

//Ldarg_1 = object – not needed

Ldarg_2 = EventArgs

Ldsstr = EventInfo.Name

NOT calling Ldarg_1 discards the object part of the dynamic method signature, which is OK, because that just represents EventSource anyway, and we have a reference to that already.

One important thing to note, though, is that when calling CreateDelegate on DynamicMethod it is critical to pass in “this” as the target – otherwise when the method you generated tries to access member variables, you’ll get illegal memory access errors. Also subtle, if you are creating a dynamic method that you intend to bind to an instance of an object, then the DynamicMethod needs to be created using the secret, full signature of MyMethod(EventRecorder,object,EventArgs) NOT just MyMethod(object,EventArgs) as you would expect. You can see this being taken care of in the GetDelegateParameterTypes method. This piece of info was not in the MSDN sample, and was a just a joy to figure out 🙂

By the way – a great way to figure out just what IL you need is to write the method you are hoping to generate, compile it, then view the IL in ILDASM.exe. Then you can either blindly translate the IL into Opcode.xxx calls, or you try to understand why it is doing what it is doing and modify according to your needs, but I probably never would have figured out the Ldarg_0 / Ldarg_2 mystery on my own – ILDASM saved my butt.

I need to find a better way of debugging this stuff, but the fact of the matters is that once you see what is going on, IL isn’t really any more complicated than anything else, it is just far more verbose and cryptic when you get it wrong 🙂

The rest of EventRecorder is nothing special. The sample includes unit tests and a simple windows forms example.

Here are some resources:

DynamicMethod.CreateDelegate Method

How to hook up a delegate using reflection

Reflection.Emit tidbits

Introduction to creating types with Reflection.Emit, DymamicMethod

nServiceBus Management Extensions – new CodePlex project

I just launched a new open source project on CodePlex, NSB Management Extensions. This purpose of this project is to provide endpoint management, such as endpoint heartbeat monitoring & node performance monitoring, which exists in the initial release, as well as some more advanced services such as service/endpoint repositories, event broker with server-side subscription rules, a processing pipeline for the MSMQ Transport, etc.

The project can be found here: http://www.codeplex.com/NSBManagement

Unit Testing Custom .NET Configuration Classes

I am currently in the process of writing some custom .NET Configuration classes, such as custom ConfigurationHandler implementations, ConfigurationElementCollection, etc. Configuration classes need to be tested just like any other code, especially if they contain any behavior beyond the simple mapping of an XML property to a class property. It turns out the .NET Configuration API makes this pretty easy:

 

    [TestFixture]
    public class ConfigurationTestFixture
    {
        [Test]
        public void TestCustomConfig()
        {
            var cfg = GetTestConfiguration();
            Assert.That(cfg, Is.Not.Null);

            var mySection = cfg.GetSection("mySection") as mySection;
            Assert.That(mySection, Is.Not.Null);
            Assert.That(mySection.CustomProp,Is.EqualTo("configuredValue"));
            ...

        }

        private System.Configuration.Configuration GetTestConfiguration()
        {
            var map = new ExeConfigurationFileMap()
                          {
                              ExeConfigFilename =
                              Path.Combine(AppDomain.CurrentDomain.BaseDirectory,
                              "TestApp.config")
                          };

            return ConfigurationManager.OpenMappedExeConfiguration(
                    map, ConfigurationUserLevel.None);
        }

 

For this to work you’ll need a configuration file with the appropriate XML to test your classes stored at the root of your test project with the Copy To Output Directory property set to Copy If Newer. You could use any path to create your ExeConfigurationFileMap, but for me putting the file at the root seemed the easiest solution.

image

.NET Configuration – THE article on customizing the configuration of your app

In looking for a palatable way to add configuration file support to some components I’m writing I looked at a number of articles on the topic, all of which discussed some interesting aspect of the configuration. This article, however, covers it all. It is a little long, but well organized so you can find just the parts you need. If you ever engage in creating a configuration section for your .NET 2.0+ app, this is the reference.

http://www.codeproject.com/KB/dotnet/mysteriesofconfiguration.aspx

 

That being said, here’s a totally different approach to configuration using the XML Serializer. You would lose some validation capabilities, but you gain virtually unlimited flexibility in your object model and you can write whatever simple configuration model you like without worrying about the configuration namespace classes.

http://www.15seconds.com/issue/040504.htm