Tag Archive for Reflection

Moq, Callbacks and Out parameters: a particularly tricky edge case

In my current project we’re using Moq as our mocking framework for unit testing. It’s a very nice package – very simple, very intuitive for someone who has his wrapped around basic mocking concepts, but tonight I ran into an annoying limitation that, while rare, impeded my tests considerably.

Consider the following code:

  1: public interface IOut
  2: {
  3:    void DoOut (out string outval);
  4: }
  6: [Test]
  7: public void TestMethod()
  8: {
  9:   var mock = new Mock();
 10:   string outVal = "";
 11:   mock.Setup(out => out.DoOut(out outVal))
 12:       .Callback<string>(theValue => DoSomethingWithTheValue(theValue));
 13: }

What this code SHOULD do is create a mock object for the IOut interface that, when called with an out parameter, both assigns a value to it, and does something with the value in the Callback.

Unfortunately, this does not work.

The reason it doesn’t work is that the Callback method has many overloads, but they are all to various variants of the Action<> delegate. Either Action, which receives one parameter, or to Action, which receives three. None of these support out parameters. But none of these delegates has a signature with an out parameter. The result, at runtime, would be an error to the effect of

“Invalid callback parameters <string> on object ISetup<string&>”

Note the highlighted bits – The Setup method referred to a string& (a ref/out param), while the Callback inferred an Action delegate, which expectes a regular string param.

So what CAN we do?

The first option is submit a patch to the Moq project. It’s open-source, and a solution might be appreciated, especially since the project’s lead, Daniel Cazzulino, pretty much acknowledged that this is not supported right now. I might do that later, but right now it’s the middle of the night and I just want my tests to pass. So I manage to hack together this workaround which does the trick:

  1: public static class MoqExtension
  2: {
  3:    public delegate void OutAction (out TOut outVal);   
  4:    public static IReturnsThrows 
  5:                         OutCallback
  6:                                  (this ICallback mock, 
  7:                                   OutAction action) 
  8:                                      where TMock : class
  9:    {
 10:       mock.GetType()
 11:           .Assembly.GetType("Moq.MethodCall")
 12:           .InvokeMember("SetCallbackWithArguments", 
 13:                         BindingFlags.InvokeMethod 
 14:                             | BindingFlags.NonPublic 
 15:                             | BindingFlags.Instance, 
 16:                         null, mock, new object[] {action});
 17:       return mock as IReturnsThrows;
 18:    }
 19: }


We’ve created a new delegate, OutAction, that has out T as its parameters, and we’ve added a new extension method to Moq, OutCallback, which we will use instead of Callback. What this extension method does is use brute-force Reflection to hack into Moq’s internals and call the SetCallbackWithArguments method, which registers the Callback with Moq. Yes, it even works. I’m as surprised as you are.

Note and Caveats:

1) This code works for the very specific void Function (out T) signature. You will have to tailor it to the specific methods you want to mock. To make it generic, we’ll have to create a bucket-load of OutAction overloads, with different combinations of out and regular parameters.

2) This is very hacky and very fragile. If Moq’s inner implementation changes in a future version (the one I’m using is 4.0.10827.0), it will break.

3) I don’t like using out params, usually, but this is a 3rd party library, so I have to work with what I got.

Comments? Questions? Scathing criticisms on how ugly my code is? A different, simpler method of accomplishing this that I totally missed? Bring’em on.

Reflecting over an Event

A coworker (Hey, Evgeny!) came to me with a puzzler today. He has an object that exposes an event, and he wants to know whether he's already subscribed to that event.

Two things immediately came to mind – the first was that he really shouldn't be doing that, and the second was to suggest that if the reason for this is to avoid multiple registrations, he can always call -= and then += afterwards, thus making sure he's subscribed only once. Having established that, I got down to thinking about it.

I started checking out what reflection can do for me. I could easily get the EventInfo object for the event using:


but that proved fruitless – I could get the Add and Remove MethodInfos, add a new handler and even get the delegate type for that event, but not the actual instance of the delegate. So I started thinking again.

An event in the .NET Framework is basically a wrapper around a multicast delegate. Just like a property can be a wrapper around a private data field. Rather than exposing the delegate directly, we expose a more limited subset of functionality (subscribe and unsubscribe) rather than allow my consumers to mess with my internal delegate list.

By that logic, it stands to reason that there should be an internal, private member holding the delegate itself. Probably having the same name as the event. A quick check confirmed that:

myObj.GetType().GetFields(BindingFlags.NonPublic | BindingFlags.Instance):
[0]: {System.EventHandler`1[System.EventArgs] MyEvent}

Right. EventHandler is my delegate type (that ugly format is the internal representation of generic types) and MyEvent is the name of the event. Using this, it's a piece of cake to get the value of the field and cast it to the multicast delegate:

FieldInfo delegateField = myObj.GetType().GetField(“MyEvent”, BindingFlags.NonPublic | BindingFlags.Instance);
EventHandler del = delegateField.GetValue(myObj) as EventHandler;

And once we had that – it's a simple matter of iterating the invocation list and seeing whether I've registered already:

foreach (EventHandler handler in del.GetInvocationList())
    if (handler.Target == this)
        return true;

Now, I'm not saying this is a good technique – it's better not to reach a point where I don't know if I've registered or not. But still, it's good to know.

I've attached the full code listing, which is more complete, has comments and a few checks so we don't crash. Enjoy.

UPDATE: This solution is all nice and well, but as Evgeny pointed out in the comments below, this doesn't work with COM Objects. In fact, Reflection as a whole seems to be very limited, always returning __COMObject as the reflected type. Anyone know how to get more information from the RCW?

Crossing the line – Reflection and Reality

When we’re working Reflection, we tend to think in different terms than we do when we’re actually calling methods. There’s an extra level of abstraction in everything we do. Translating between these levels of abstraction isn’t always easy or intuitive, so I’ll try to go over some common paths, using this following class definition for my examples:

using System.Reflection;
public delegate void MyDelegate();
public class MyClass

    public void MyMethod() { } 
    private void MyPrivateMethod() { } 
    public static void MyStaticMethod() { } 
    public int MyField; 
    public int MyProperty 
        get { return MyField; } 
        set { MyField = value; }

Concrete -> Reflection

1. Objects

MyClass myObject = new MyClass();
Type myType = myObject.GetType();

2. Classes

Type myType = typeof(MyClass);

Note: The examples from now on will assume we have the myObject and myType variables as defined above.

3. Public Instance Methods

MethodInfo method = myType.GetMethod(“MyMethod”);

4. Private Instance Methods

MethodInfo privMethod = myType.GetMethod(“MyPrivateMethod”, BindingFlags.NonPublic | BindingFlags.Instance );

5. Static Methods

MethodInfo statMethod = myType.GetMethod(“MyStaticMethod”, BindingFlags.Public | BindingFlags.Static);

6. Fields

FieldInfo fi = myType.GetField(“MyField”);

Note: For static or non-public fields, overloads exist similar to those for methods above.

7. Properties (with their associated Get/Set methods)

PropertyInfo pi = myType.GetProperty(“MyProperty”);

MethodInfo getMethod = pi.GetGetMethod();
MethodInfo setMethod = pi.GetSetMethod();

Note: For static or non-public properties, overloads exist similar to those for methods above.

8. Delegates

MyDelegate del = myObject.MyMethod;
MethodInfo mi = d.Method;


Reflection -> Concrete

1. Objects
(note the cast)

MyClass myObj = Activator.CreateInstance(myType) as MyClass;

2. Methods (invoking)

For a static method, we will supply null for the first parameter (the instance).

mi.Invoke(myObj, new object[] {} );

3. Fields

int value = (int)fi.GetValue(myObj);

4. Properties

Unlike fields, properties can take a set of parameters. Either parameterized properties in VB or indexers in C#.

int value = (int)pi.GetValue(myObj, null);

5. Delegates

Delegate to static method:

MyDelegate del = (MyDelegate) Delegate.CreateDelegate(typeof(MyDelegate), method);

Delegate to instance method:

MyDelegate del = (MyDelegate)Delegate.CreateDelegate(typeof(MyDelegate), myObj, method.Name);

Note that there is no syntax to create an instance delegate from a MethodInfo; for some reason we only have a weakly-typed overload that accepts the method name as a string. Only the first overload, for static methods, receives a strongly typed MethodInfo.

From Accessors to Properties

For various debugging processes, I find myself needing to find several bits of runtime information for my properties. This means I want to get the property’s PropertyInfo object by Reflection when that property’s code is running.

The problem is that Properties are C# constructs, not IL constructs. My property’s get accessor is actually compiled into a get_MyProp() method. This means that while I can easily get the MethodInfo for the current accessor, there doesn’t appear to be any easy way of getting the PropertyInfo from the MethodInfo.

The ugly way, of course, is to take the method’s name, strip the first four characters from it and do a GetProperty() with that name – and that works, of course, but causes me actual physical pain to use:

PropertyInfo prop = accessorMethod.ReflectedType.GetProperty(accessorMethod.Name.Remove(0, 4));

Is there a better, simpler way I’m missing?

Non-generic default values in C#? Why not?!

A relatively obscure new keyword in C# 2.0 is the default(T) keyword.
It’s shorthand for checking if the given generic parameter T is a value type or reference type. If it’s a reference type, it returns null. Otherwise it returns 0/false/0.0 or whatever the default value for the type is.

For some reason, though, it can only be used on generic parameters. Why can’t I use default(typeof(int)) to get 0? Or, more realistically, default(myUnknownType) to return the default value?

A workaround is to check if it’s a value type with reflection, but it’s cumbersome:

if (!myType.IsValueType)
   return null;
   return Activator.CreateInstance(myType);

Luckily, value types (including structs) always have a default parameterless constructor. We can’t even override it – it will always initialize all struct members to their default values.

This little code snippet can now be wrapper in some sort of function – call it Default() or GetDefault() or even @default() if you want to keep it as close as possible to the generic keyword.

It’s interesting to note that the generic keyword relies on the InitObj IL opcode to initialize the object. If we could embed IL directly in our code we could call this directly. We can do it via Reflection.Emit and DynamicMethods but I feel that’s going a bit far overboard when the solution above works just as well.


In TechEd Israel 2006, I listened to Roy Osherove‘s excellent talk on the new reflection features in .NET 2.0 – a great assortment of topics on things ranging from DynamicMethods to the ReflectionOnly- set of properties.
One of the things he mentioned was that the GetCustomAttributes method that’s exposed by various reflection types was unsafe. When the method returns the collection of custom attributes, it has to instantiate each one of them, and this means calling the constructor on each one of them. This could be the “crack in the door” for an attacker to use an extensible plug-in architecture to slide his own code by inheriting a custom atttribute with malicious constructor code and decorating a class with it.
The solution in .NET 2.0 comes from the CustomAttributeData class, which has a single static method – GetCustomAttributes – which returns the list of attributes without calling their constructors. This seems a cleaner and safer solution, and I couldn’t wait to go and fix up my reflection code in the current project with it.

The problem with this implementation, as always, is in the little details. The GetCustomAttributes method we have on the reflection types are implemented via the ICustomAttributeProvider interface, which is implemented by Type, ParameterInfo, MethodInfo and all those other attribute-supporting constructs. The GetCustomAttribute method of the CustomAttributeData class, though, has several overloads taking MemberInfos, Assemblys, ParameterInfo or Module – the four classes that implement ICustomAttributeProvider. This means that while it is theoretically equivalent to the older method, it does not allow me to cast my member/type/assembly to an ICustomAttributeProvider and perform operations on it – I have several attribute-related functions that take either a Type or a Property, so in this case I can cast them both to MemberInfos and use that as my lowest common denominator. But what if I had needed to handle Assemblies as well?

A rather annoying ommision. Whenever I’m forced to use concrete classes rather than base-classes or interfaces, I get slightly nervous. It may be fine for the time being, but I know that somewhere down the line, I’ll try to refactor something and get bitten.

EDIT: searching Google, it seems that I am the very first to use the “Reflection.Omit” pun, or at least to publish it on a Googleable medium. Cool.