F#: Use reflection to call a private or protected method

This isn’t anything ground breaking so if you are expecting it to be, tough luck. The world doesn’t revolve around you. It revolves around me.

Making the switch to F# has caused me to redo a lot of older framework stuff and using reflection to call methods is part of that stuff. I could sit here and go on about something and waste your time, but I’ll be nice this time.

open System
open System.Reflection
 module ReflectionUtility =
  //This is used to make sure the GetMethod method doesn't skip private or protected
  let public BindingFlagsToSeeAll =
    BindingFlags.Static |||
    BindingFlags.FlattenHierarchy |||
    BindingFlags.Instance |||
    BindingFlags.NonPublic |||
    BindingFlags.Public;

  type MethodReflection public() =
    //Get the method by the method name from the class type
    member private x.FindMethodInfo<'targetClass>(methodName:String, source:'targetClass) =
      (source.GetType()).GetMethod(methodName, BindingFlagsToSeeAll)

    //Call the find method and run the found method
    member public x.ExecuteMethod<'returnType, 'target>(source:'target, methodName:String, argTypes:Type[], args:Object[]) =
      let info = x.FindMethodInfo(methodName, source)
      info.Invoke(source, args) :?> 'returnType

As you can see, this is extremely easy and short to use. I would suggest adding in some sort of caching if you are using this for anything that needs performance as I’m pretty sure reflection is still somewhat expensive. Most likely if I were caching anything it would be the method info.

If you’re new to F#, or due to an unfortunate turn of events ended up here, you might be wondering what all that ‘word stuff is or how the hell FindMethodInfo is returned

Well the ‘ notation is simply the way F# defines generic types.  It may look odd compared to C# but one nice thing is you never have to worry that your generic constraint might mirror the name of a variable/parameter/field.

The FindMethodInfo does have a return.  F# assumes that the last line in the method is the return.  This is really nice feature that saves a little bit of time by not having to type Return.  The other nice thing about it is that F# will infer the method’s return type by the last line so you never have to type out the return type for a method:

C#:

  public string ReturnString()
  {
    return "";
  }

F#
  member public x.ReturnString() =
    ""

And that’s one reason why all the cool kids use F#.

Duck Typing my way to a Universal String Convert

So being the beacon of ignorance in the fog of brilliance, I had no idea what Duck Typing was. In short it’s the idea of assuming a class’s type based on the methods it holds.

Say you have 5 different classes, none of which share an inheritance tree. Now let’s say you have a method that takes in any object and uses the SeanIsAwsome method on the object. You could make sure that every object sent in has that method by using an interface that all the objects sent in share.

    public void SomeMethod(ISeanRules inParameter)

What if you want to send in a bunch of objects that don’t share the same interface/base class? Well you base it on what methods the class holds. If the class has the SeanIsAwsome method, then you call it. If not, well you could throw an exception, do nothing, go jogging, eat bacon, ect. That part is up to you.

The problem was that I wanted to create a universal convert that would take in a string and convert it to the 8 billion (ballpark figure) value types in C#. Now what I wanted to do is use the famous TryParse method so my first hope was that TryParse was a method on an interface they all shared. Yeah no. So next thought was to use the Duck Typing principle and say, “Hey jackass, you have a TryParse method? Yeah? Good. Use it.” ‘Course I had to find a way to do that. Turns out it wasn’t too bad.

public static class ConvertFromString
{
  public static T? ConvertTo<T>(this String numberToConvert) where T : struct
  {
    T? returnValue = null;

    MethodInfo neededInfo = GetCorrectMethodInfo(typeof(T));
    if (neededInfo != null && !numberToConvert.IsNullOrEmpty())
    {
      T output = default(T);
      object[] paramsArray = new object[2] { numberToConvert, output };
      returnValue = new T();

      object returnedValue = neededInfo.Invoke(returnValue.Value, paramsArray);

      if (returnedValue is Boolean && (Boolean)returnedValue)
      {
        returnValue = (T)paramsArray[1];
      }
      else
      {
        returnValue = null;
      }
    }

    return returnValue;
  }
}

A whaaaa?

Ok this might look odd, but it’s really simple. If it doesn’t look odd then chances are you’re smarter than me and you shouldn’t be here anyhow. First part is simple:

  public static T? ConvertTo<T>(this String numberToConvert) where T : struct

Due to this being a extension method (Opps forgot to tell you that part) I have to declare this static method in a static class. Basically I am taking in a string and returning a nullable version of whatever type I specific in the call.

    T? returnValue = null;

    MethodInfo neededInfo = GetCorrectMethodInfo(typeof(T));

Remember that MethodInfo method I had explained in the last post? The next part you might remember too, but I’m not betting on it.

    if (neededInfo != null && !numberToConvert.IsNullOrEmpty())
    {
      T output = default(T);
      object[] paramsArray = new object[2] { numberToConvert, output };
      returnValue = new T();

      object returnedValue = neededInfo.Invoke(returnValue.Value, paramsArray);

Ok so I have the method info, now I have to create the list of parameters to send in with the invoke. Pretty straight forward. If things went well, returnedValue should be a boolean. However, just incase:

    if (returnedValue is Boolean && (Boolean)returnedValue)
    {
      returnValue = (T)paramsArray[1];
    }
    else
    {
      returnValue = null;
    }

So if the returnValue is true and boolean, then the tryParse was successful. With that in mind, I still have to get the converted value. If it had not been successful than I am just going to return null since this is just meant for converting and not for whether or not it could be. It is just assumed that if it’s null, then it could not be converted at this time.

And now for the use:

  decimal? converted = someString.ConvertTo<decimal>()

An boom, you have a universal convert. YAY!

  using System;
  using System.Reflection;

Return Out Variables Using GetMethod

So I ran into a problem today. I wanted to call a method (TryParse) off a type using relfection, but the catch is that there is an out parameter. At first I though, “Hey, I just give it the type and it will find it. Not so lucky. See when you call GetMethod you have to supply a list of parameters. why? because if you don’t, the name alone could return any number of methods named the same thing. By using a parameter list, it in essence narrows it down to one. Say you look at decimal.TryParse which expects a string and an out parameter of type decimal. Would think it is:

  Type[] paramTypes = new Type[2] { typeof(string), typeof(decimal) };
  returnValue = typeToCheck.GetMethod("TryParse", paramTypes);

No dice. Looks ok until you actually look at the type of the second parameter. It’s actually “decimal&”, meaning there is a reference attached to it. This makes sense since Out will switch the pointer of the old parameter sent in to whatever you create in the method. Problem is when you trying to find the method you are looking for “decimal” != “decimal&”. Now this looks like a big problem, but it’s actually easy to solve.

  Type[] paramTypes = new Type[2] { typeof(string), typeof(decimal).MakeByRefType() };

See the difference? Turns out Microsoft already thought this one through. The MakeByRefType method allows you to simulate an out parameter. Here’s the method in full to get the MethodInfo:

  private static MethodInfo GetCorrectMethodInfo(Type typeToCheck)
  {
    //This line may not mean much but with reflection, it's usually a good idea to store
    //things like method info or property info in a cache somewhere so that you don't have
    //have to use reflection every time to get what you need.  That's what this is doing.
    //Basically I am using the passed in type name as the key and the value is the methodInfo
    //for that type.
    MethodInfo returnValue = someCache.Get(typeToCheck.FullName);

    //Ok, now for the reflection part.
    if(returnValue == null)
    {
      Type[] paramTypes = new Type[2] { typeof(string), typeToCheck.MakeByRefType() };
      returnValue = typeToCheck.GetMethod("TryParse", paramTypes);
      if (returnValue != null)
      {
        someCache.Add(typeToCheck.FullName, returnValue);
      }
    }

    return returnValue;
  }

Now we’re not done yet, are we? No. That just gets the methodInfo needed. Now how do I call it and get a value back? Well that’s pretty easy too:

  MethodInfo neededInfo = GetCorrectMethodInfo(typeof(decimal));
  decimal output = new decimal();
  object[] paramsArray = new object[2] { numberToConvert, output };
  object returnedValue = neededInfo.Invoke(returnValue.Value, paramsArray);

  if (returnedValue is bool && (bool)returnedValue)
  {
      returnValue = (decimal)paramsArray[1];
  }
  else
  {
    returnValue = null;
  }

So first part is actually calling the method we now have:

  MethodInfo neededInfo = GetCorrectMethodInfo(typeof(decimal));
  decimal output = new decimal();
  object[] paramsArray = new object[2] { numberToConvert, output };
  object returnedValue = neededInfo.Invoke(returnValue, paramsArray);

So basically you take the variables, put them into an array, and then pass that array trough the invoke method. Nice thing is when the two variables are sent into the method, you don’t have to flag output as an Out parameter.

Now for the FINALLY ITS OVER

  if (returnedValue is bool && (bool)returnedValue)
  {
      returnValue = (decimal)paramsArray[1];
  }
  else
  {
    returnValue = null;
  }

You would think that the “output” variable you sent through .Invoke would hold the needed value. Too bad. You actually have to look at the object array passed in to get the value of the Out parameter. Kind of annoying, but deal with it.

And there you have it, how to not only find a methodInfo with an out parameter, but how to get the value back too. YAY

  using System;
  using System.Reflection;

My next post will show why I had to figure this out and I promise it will be worth it.

Filling a Private Field on a Base Class Using Reflection

Ok here’s the next step in this testing kick. So now you have your test classes that create classes. Swell. Problem is, there are private fields on the base class of whatever class you are creating. So you’re screwed, right? Not really. Now what I am about to do is nothing new. It’s just basically using Reflection and FieldInfo to fill a field on a base class. Actually very easy. Here’s the code for the example.

using System;
using System.Collections.Generic;
using System.Reflection;

public class UserBase
{
  private Boolean _isBaseUser;

  public UserBase()
  {
      _isBaseUser = true;
  }

  public Boolean IsBaseUser
  {
      get
      {
          return _isBaseUser;
      }
  }
}

public class MainUser : UserBase
{
  //Simple list used to "cache" the field info so reflection doesn't have to be used
        //again for a type that has already been used.
  private static Dictionary<Type, List<FieldInfo>> typeToInfoList;

  /// <summary>
        /// This is used to fill in the needed field on the passed in object.  This is done by reflection/
        /// FieldInfo.  Basically you get the field info you want off the type, then you use the info to
        /// fill the field on the object.  
        /// </summary>
        /// <param name="objectToFill">This is the object that needs the field changed.</param>
        /// <param name="fieldName">This is the name of the field.</param>
        /// <param name="value">This is the value to be set.</param>
        /// <param name="typeToCheck">This is the type of the class that the field resides.</param>
  public static void FillField(Object objectToFill, String fieldName, Object value, Type typeToCheck)
  {
      List<FieldInfo> fieldInfoList;
      FieldInfo neededFieldInfo;
      Boolean heldInfoList;

      if (typeToInfoList == null)
      {
          typeToInfoList = new Dictionary<Type, List<FieldInfo>>();
      }
      //Check to see of the list already has the field info and save that 
          //boolean for later use.
      heldInfoList = typeToInfoList.ContainsKey(typeToCheck);
      //If it is in the "cache", grab it.  If not, create a new list
          //for the passed in type.
      fieldInfoList = heldInfoList ? typeToInfoList[typeToCheck] : new List<FieldInfo>(typeToCheck.GetFields(BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public));

     //Now just look for the needed field info in the list. 
     neededFieldInfo = fieldInfoList.Find(currentItem => currentItem.Name == fieldName);
      //Use the field info to set the value on the object.
      neededFieldInfo.SetValue(objectToFill, value);

      //Store the field info list if it isn't being stored already.
      if (!heldInfoList)
      {
          typeToInfoList.Add(typeToCheck, fieldInfoList);
      }
  }

  //Simple constructor to create the user.
  public static MainUser Create()
  {
      MainUser testUser;

      testUser = new MainUser();

      return testUser;
  }
}

That’s pretty much it. What the hell is all that? Well basically you have the UserBase as the base class for the example. MainUser that in inherits UserBase. The FillField method that does all the work. And lastly, the dictionary used as a lame cache for this example. Why cache anything? Well everything you get the field info, reflection is used. This can be expensive. So why bother getting the same field info for the same type every time this method is called? Just store it somewhere so that if the same class type is passed through again, you can easily access the field info for the class without going for reflection again.

Here’s an example of the use:

using Microsoft.VisualStudio.TestTools.UnitTesting;

 [TestClass]
 public class FillFieldTest
 {
     [TestMethod]
     public void FillField_CheckFieldForChange()
     {
         MainUser testUser;

         testUser = new MainUser();
         Assert.IsTrue(testUser.IsBaseUser);

         MainUser.FillField(testUser, "_isBaseUser", false, typeof(UserBase));
         Assert.IsFalse(testUser.IsBaseUser);

         MainUser.FillField(testUser, "_isBaseUser", true, typeof(UserBase));
         Assert.IsTrue(testUser.IsBaseUser);
     }
 }

First test is checking to see if the IsBaseUser property is true. This will be true since UserBase sets _isBaseUser to true on instantiation.

Second test is checking to see if the FillField method worked correctly.

Third test is really just to step through a second time so you can see how the quasi-caching works.