Planet ASP.NET MVC

Private reflection allows you to access private and internal members in other assemblies.  Generally, it’s considered to be a bad thing to do, as it ties you to undocumented implementation details which can later break you.  Also, it’s not usable in medium trust.

My purpose in this post is not to encourage anyone to use private reflection in situations where you would not have done it anyway.  Instead, my purpose is to show you how to do it much more easily if you decide that you need to use it.  Putting it a different way, I’m not telling you to break the law, but I’m telling you how to break the law more efficiently if that’s what you’re into!

Ok, that was my little disclaimer to avoid getting in trouble.  My lawyer made me do it!  Or would have if I had one.

The scenario

So let’s look at a sample scenario.  Say you’re using an assembly that has code like this:

public class Foo1 {

    private Foo2 GetOtherClass() { … }

}

internal class Foo2 {

    private string SomeProp { get { .. } }

}

And say you have an instance foo1 of the public class Foo1 and your evil self tells you that you want to call the private method GetOtherClass() and then get the SomeProp property off of that.

The solution using good old private reflection

Here is how you can write this code the old fashion way using private reflection.

object foo2 = typeof(Foo1).InvokeMember(“GetOtherClass”,

    BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.InvokeMethod,

    null, foo1, null);

PropertyInfo propInfo = foo2.GetType().GetProperty(“SomeProp”,

    BindingFlags.Instance | BindingFlags.NonPublic);

string val = (string)propInfo.GetValue(foo2, null);

Sure that works, but ouch, that’s ugly!

The dynamic solution

Now to be clear, C# 4.0 dynamic is not going to help you with this out of the box, because it doesn’t support private reflection (I suppose the C# designers didn’t want to encourage that).  So if you try to write:

string val = ((dynamic)foo1).GetOtherClass().SomeProp;

This will blow up with the error “RuntimeBinderException: ‘LibraryWithPrivateMembers.Foo1.GetOtherClass()’ is inaccessible due to its protection level”.

To get around this, we need to write our own DynamicObject implementation which will perform private reflection under the cover.  With that library, we can now write (after importing the PrivateReflectionUsingDynamic namespace):

string val = foo1.AsDynamic().GetOtherClass().SomeProp;

So we call AsDynamic() on our object (it’s an extension method), which gets us our special DynamicObject implementation.  Once we have that, we can happily write a tiny bit of nice looking dynamic code to replace the ugly reflection mess!

How does it all work

I attached a full VS2010 solution with unit test coverage, so I’m not going to show you the whole code here (it’s over 200 lines).  Instead, I’ll describe it at a high level.

I actually wrote a few other posts before where I wrote custom DynamicObject implementation (named PrivateReflectionDynamicObject).  The general idea is that you override various methods that get called by the dynamic engine when it needs to execute the code.  e.g. when it needs to get a property value, it calls your TryGetMember method.  To call a method, it calls your TryInvokeMember method.

The difference between my previous posts and what I did here is that PrivateReflectionDynamicObject is much more complete, because it’s trying to handle most of the things you might want to using private reflection.  Specifically, it handles:

• Getting and setting properties


• Getting and setting fields (note that properties and fields are the same thing in the dynamic world, but different in the reflection world)


• Calling methods


• Getting and setting values into arrays


• Getting and setting values into indexed properties (e.g. string this[string s] { … })


• Type conversions

The implementation of all this is simply to turn around and use private reflection.  So in the end, you’re executing mostly the same code as if you had done it manually, but with a lot less pain.

One interesting thing to note is that objects returned by this logic need to be themselves wrapped into a PrivateReflectionDynamicObject.  This is necessary in order to able to write foo1.AsDynamic().GetOtherClass().SomeProp.  Otherwise, GetOtherClass() would just return a Foo2 object, and you would not be able to access the SomeProp property.  In a twisted way, you might call that a fluent API.

And finally, then there is the AsDynamic extension method, which makes it easy to access this functionality.  It just has:

public static class PrivateReflectionDynamicObjectExtensions {

    public static dynamic AsDynamic(this object o) {

        return PrivateReflectionDynamicObject.WrapObjectIfNeeded(o);

    }

}

Usually, I’m hesitant to add extension methods to object, but in this case it seemed appropriate, since you can potentially do private reflection on any object.  Also, it’s in a specific namespace, so the method only shows up if you choose to import it.

You can unzip the attach solution and try it on VS2010.  I have a somewhat newer build, but I think it should run on beta 2.

First, I’ll start with a little disclaimer: this post is not about whether using dynamic is better/worse than static typing.  Instead, it’s about making it more convenient to use dynamic if you choose to go that route.  Clearly, some people dislike dynamic, as you can see in the comments in that post from Phil Haack, and for the most part, all the key arguments for/against have been made.

So anyway, let’s proceed… Recently, a few people have experimented with extending their view pages from ViewPage<dynamic>.  The idea is to then be able to access model data using the more convenient dynamic syntax.  e.g. check out this thread on StackOverflow, as well as Phil’s post I mention above.

One limitation that people are hitting is that you can’t easily pass an anonymous object as your model, because anonymous types are internal.

What we’re trying to write

e.g. Let’s say we’re trying to write this code in the controller:

public class HomeController : Controller {

    public ActionResult Index() {

        return View(

            new {

                Message = “Welcome to ASP.NET MVC!”,

                Date = DateTime.Now

            });

    }

}

Note that we’re passing an anonymous object as the model.  The main reason to do this is to avoid the need to create an explicit ViewModel type.  Obviously, that’s controversial, but it should be viewed more as a simpler alternative to writing

ViewData["Message"] = “Welcome to ASP.NET MVC!”;

ViewData["Date"] = DateTime.Now;

return View();

And then you’d change your view to have Inherits=”System.Web.Mvc.ViewPage<dynamic>”, which ideally would let you write something like this:

<asp:Content ID=”indexContent” ContentPlaceHolderID=”MainContent” runat=”server”>

    <h2><%: Model.Message %></h2>

    <p>

        The date is <%: Model.Date %>

    </p>

</asp:Content>

Which is simpler than having to dig things out of the view data dictionary through string indexing.

But the default dynamic binder won’t let us!

Unfortunately, if you try to run this code, it’ll blow up with this error: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: ‘<>f__AnonymousType1<string,System.DateTime>.Message’ is inaccessible due to its protection level

The reason for this is that the anonymous type being passed in the controller in internal, so it can only be accessed from within the assembly in which it’s declared.  Since views get compiled separately, the dynamic binder complains that it can’t go over that assembly boundary.

But if you think about it, this restriction from the dynamic binder is actually quite artificial, because if you use private reflection, nothing is stopping you from accessing those internal members (yes, it even work in Medium trust).  So the default dynamic binder is going out of its way to enforce C# compilation rules (where you can’t access internal members), instead of letting you do what the CLR runtime allows.

Solution: write our own!

I’m not sure why it was designed this way, but the good news is that it’s easy to work around by writing our own custom DynamicObject which binds through private reflection!  I’ve written a couple posts that make use of custom DynamicObjects (find them here), and the basic concept is the same: given the name of a property, write whatever code you want to produce its value.

Here, we’re not only going to write a custom Dynamic Object, but also a custom DynamicViewPage that uses it.  And doing all this takes surprisingly little code.  Here is the full implementation:

public class DynamicViewPage : ViewPage {

    // Hide the base Model property and replace it with a dynamic one

    public new dynamic Model { get; private set; }

    protected override void SetViewData(ViewDataDictionary viewData) {

        base.SetViewData(viewData);
        // Create a dynamic object that can do private reflection over the model object

        Model = new ReflectionDynamicObject() { RealObject = ViewData.Model };

    }
    class ReflectionDynamicObject : DynamicObject {

        internal object RealObject { get; set; }
        public override bool TryGetMember(GetMemberBinder binder, out object result) {

            // Get the property value

            result = RealObject.GetType().InvokeMember(

                binder.Name,

                BindingFlags.GetProperty | BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic,

                null,

                RealObject,

                null);
            // Always return true, since InvokeMember would have thrown if something went wrong

            return true;

        }

    }

}

As you can see there is not that much to it: when we need to look up a property value, we use private reflection and that’s the end of it.

And now it all works!

Once we have this, all that’s left to do is use it as our base class for the view, e.g.

<%@ Page Language=”C#” MasterPageFile=”~/Views/Shared/Site.Master” Inherits=”MvcHelpers.DynamicViewPage” %>

And we’re then able to write exactly what we wanted above in the controller and the view, without hitting any access issues.

The full VS2010 project is attached to this post.

Update (11/7/09): fixed Execute() method per Richard’s suggestion to wrap IDataRecord instead of Reader.

Recently, I started playing around with C# dynamic, and blogged how it could be used to call static class members late bound.  Today, I was talking to Phil Haack, who I think had talked to ScottGu, and he mentioned that it would be cool to use dynamic to simplify data access when you work directly with SQL query.  So I thought I’d play around with that, and it didn’t take much code to make it work nicely.

So the scenario is that you’re not using any fancy O/R mapper like LINQ to SQL or Entity Framework, but you’re directly using ADO.NET to execute raw SQL commands.  It’s not something that I would personally do, but there are a lot of folks who prefer this over the higher level data access layers.

So let’s look at an example of what we’re trying to improve.  Let’s borrow an MSDN sample about SqlCommand:

string commandText = “SELECT OrderID, CustomerID FROM dbo.Orders;”;

using (var connection = new SqlConnection(Settings.Default.NorthwindConnectionString)) {

    using (var command = new SqlCommand(commandText, connection)) {

        connection.Open();

        using (SqlDataReader reader = command.ExecuteReader()) {

            while (reader.Read()) {

                Console.WriteLine(String.Format(“{0}, {1}”, reader[0], reader[1]));

            }

        }

    }

}

And now let’s assume that we’re only ever interested in making one select query at a time, which lets us abstract out some of the details about the SQL Connection.  By writing some nice little helpers that make use of dynamic, we’re able to write something much simpler:

string commandText = “SELECT OrderID, CustomerID FROM dbo.Orders;”;

foreach (var row in SimpleQuery.Execute(Settings.Default.NorthwindConnectionString, commandText)) {

    Console.WriteLine(String.Format(“{0}, {1}”, row.OrderID, row.CustomerID));

}

A few things to note:

• We pretty much just make one method call, and directly get back objects that we can work with.  Contrast this with having to deal with SqlConnection, SqlCommand and SqlDataReader.


• We use a standard enumeration pattern, while SqlDataReader makes you call reader.Read() on every iteration, which looks ugly.


• And the big one: we get to access the properties directly on the row object, thanks to dynamic!  e.g. we can write row.OrderID instead of reader[0] (or reader[“OrderID”])

So how does it all work?  First, let’s take a look at the SimpleQuery.Execute helper method:

public static IEnumerable<dynamic> Execute(string connString, string commandText) {

    using (var connection = new SqlConnection(connString)) {

        using (var command = new SqlCommand(commandText, connection)) {

            connection.Open();

            using (SqlDataReader reader = command.ExecuteReader()) {

                foreach (IDataRecord record in reader) {

                    yield return new DataRecordDynamicWrapper(record);

                }

            }

        }

    }

}

So it’s basically the same as the MSDN code, except that it wraps the reader that it returns in a DataRecordDynamicWrapper, which is what makes the dynamic magic work.  Also, note that the method returns IEnumerable<dynamic>, which is why we’re able to just use ‘var row’ in the test code (which I think looks nicer than ‘dynamic row’).

So now all that’s left to look at is DataRecordDynamicWrapper, which is incredibly simple:

public class DataRecordDynamicWrapper : DynamicObject {

    private IDataRecord _dataRecord;

    public DataRecordDynamicWrapper(IDataRecord dataRecord) { _dataRecord = dataRecord; }

    public override bool TryGetMember(GetMemberBinder binder, out object result) {

        result = _dataRecord[binder.Name];

        return result != null;

    }

}

All it does is index into the data record to get the value for a given property name.

I think what I did with static methods in my last post was probably a bit of an abuse of dynamic, because we were dealing with statically types objects, and there are alternatives that would have avoided the need for dynamic.  But here, it’s I think a more legitimate use, because we’re dealing with data record objects that are intrinsically untyped.  While dynamic of course doesn’t give us strong typing, it at least makes it more pleasant to deal with.

One last thing worth noting is that to make this real, we should add support for SQL parameters, which makes it easier to write SQL code that is not vulnerable to SQL-injection attacks.  That could easily be done by passing additional params to SimpleQuery.Execute.  This sample is more of a proof of concept and an excuse to mess around with dynamic

Zipped sample is attached to this post.

By now, you’ve probably heard that C# 4.0 is adding support for the dynamic keyword, which introduces some aspects of dynamic languages to C#.  I had not had a chance to really try it, but recently I was reading Bertrand Le Roy’s post on the topic, and was sort of looking for a good opportunity to use it.

Today, I found a scenario which I thought it would work great for, but it turned out not to be supported out of the box!

The scenario is to call static class members using dynamic.  That probably sounds crazy, so let’s look at an example.  Say you have these two classes:

public class Foo1 {
    public static string TransformString(string s) { return s.ToLower(); }
    public static string MyConstant { get { return "Constant from Foo1"; } }
}

public class Foo2 {
    public static string TransformString(string s) { return s.ToUpper(); }
    public static string MyConstant { get { return "Constant from Foo2"; } }
}

Note that they are unrelated classes, but share some members with the same signature.  In a sense, you could say that they two classes share a duct tape signature.

Now here is the problem we’re trying to solve: given a System.Type object of either class (or any other random class that shares those members), how can you call those members?  Concretely, we’re trying to implement this method:

static void MakeTestCalls(Type type) {
    // Call TransformString("Hello World") on this type

    // Get the MyConstant property on this type
}

How can we implement this method? Ok, we can do it the old fashion way using reflection, e.g.

static void MakeTestCalls(Type type) {
    Console.WriteLine(type.GetMethod("TransformString").Invoke(null, new object[] { "Hello World" }));
    Console.WriteLine(type.GetProperty("MyConstant").GetValue(null, null));
}

That works, but it’s ugly.  These are the very type of things that dynamic is supposed to improve.  So my first naive attempt was to do this:

static void MakeTestCalls(Type type) {
    dynamic fooTypeDynamic = type;

    Console.WriteLine(fooTypeDynamic.TransformString("Hello World"));
    Console.WriteLine(fooTypeDynamic.MyConstant);
}

Basically, the theory was that when assigning a System.Type to a dynamic variable, it would let you call static members from it.  I didn’t really expect it to work, but I at least had to try!   And sure enough, it didn’t work, blowing up with: “Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: ‘System.RuntimeType’ does not contain a definition for ‘TransformString’”.

So I then posted the question on our internal C# list, and got a reply from C# guru Eric Lippert, basically saying that it was a potentially interesting idea but was just not supported in C# 4.0.  Fair enough, this is only the beginning of C# dynamic, and it doesn’t do everything.

But I then went back to Bertrand’s post where he gives a great sample of how you can teach dymamic new tricks by implementing a custom DynamicObject.  And it turned out to be relative simple.  Here is the class I ended up with:

public class StaticMembersDynamicWrapper : DynamicObject {
    private Type _type;
    public StaticMembersDynamicWrapper(Type type) { _type = type; }

    // Handle static properties
    public override bool TryGetMember(GetMemberBinder binder, out object result) {
        PropertyInfo prop = _type.GetProperty(binder.Name, BindingFlags.FlattenHierarchy | BindingFlags.Static | BindingFlags.Public);
        if (prop == null) {
            result = null;
            return false;
        }

        result = prop.GetValue(null, null);
        return true;
    }

    // Handle static methods
    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result) {
        MethodInfo method = _type.GetMethod(binder.Name, BindingFlags.FlattenHierarchy | BindingFlags.Static | BindingFlags.Public);
        if (method == null) {
            result = null;
            return false;
        }

        result = method.Invoke(null, args);
        return true;
    }
}

The idea is pretty simple: when the runtime needs to call something, it basically asks you to do it.  It passes you the method (or property) name and the parameters, and you take it from there. And in this case, of course, we’re using reflection.

Once we have that, the real fun starts as we’re now able to call our static members using dynamic!

static void MakeTestCalls(Type type) {
    dynamic typeDynamic = new StaticMembersDynamicWrapper(type);

    // Call TransformString("Hello World") on this type
    Console.WriteLine(typeDynamic.TransformString("Hello World"));

    // Get the MyConstant property on this type
    Console.WriteLine(typeDynamic.MyConstant);
}

Note how we wrap the type into our custom DynamicObject is order to have the dynamic invocations go through us.

Now you might say that the scenario above where you have two classes with identical static members doesn’t seem like something that would actually occur commonly in real apps.  But once you start bringing in generics, it can actually be more common.  e.g. suppose you have something like:

public class Table<T> {
    public static IEnumerable<T> Records { get { [return records from database table T] } }
}

The idea is that the class is an abstraction for a database table.  So Table<Product>.Records returns an IEnumerable<Products>, and Table<Category>.Records returns an IEnumerable<Category>.  Now suppose you’re writing some table agnostic code that can work with the data from any table.  You have a System.Type for some Table<T>, and you need to get its Records property.  Even though it seems like it’s the same Records property coming for a base class, the reality is that it’s a completely different property for each T, and C# provides no simple way of making the call.  But with the technique above, you get to access the property with a much simpler syntax than with reflection.

The zipped sample is attached to this post.