Getting stuck in the weeds

While plowing through some AutoMapper support issues this weekend, I got a rather troubling one, where a developer got a rather scary exception message:

“Operation could destabilize the runtime”

Well that’s disturbing.  It all came about because they were trying to map to a value type, a scenario which I assumed I supported.  But, there weren’t any specific tests against this scenario, so you couldn’t map to something like this:

public struct IAmAStruct
{
    public string Value { get; set; }
}

We’ll put aside the fact that value types should be immutable for now, but this was a scenario AutoMapper supported…until I started making the performance improvements of using DynamicMethod.  But let’s review what I did, I wrapped the call to the real setter method with one that was loosely typed, giving me a method that would look something like this:

private void DoIt(object source, object value)
{
    ((Source)source).Total = (int)value;
}

Now suppose the Source type is a value type, and not a reference type.  How does the value get passed in?  First, it gets boxed to an object.  Then, inside the method, it would get unboxed, and the Total property is set.  At this point, I could have stepped back and realized the impossibility of it all, that all that boxing and unboxing creates copies.  But no, I prolonged the insanity.  My next trick was to use a reference parameter, and fill in the IL for it:

private void DoIt4(ref object source, object value)
{
    var valueSource = (ValueSource) source;
    valueSource.Value = (string) value;
}

Remember, I have to use “object” as the parameter types because I’m doing a late-bound method here.  I don’t know the types until runtime, so I have to be able to use high performing calls on something that is of type Object.  But do you see the problem here?  Because I unbox “source”, I create a new ValueSource object into the “valueSource” variable.  I change the Value property on it, but not the original source object passed in.

All of this I find out after I futz around with IL for waaaaaay too long.  But, had I actually tried to create a unit test around the regular, plain jane non-IL’d method, I would have quickly seen that I was trying to attempt the impossible.  Value types aren’t reference types, and I shouldn’t try to treat them that way.

Instead, I went back to the regular reflection, MethodInfo.Invoke way.  I could try the “out” parameter way…but I was tired of wasting my time.

Moral of the story?  Don’t get stuck in the weeds!  At any point during my long, pointless journey, I could have stopped and looked to see if what I was trying to do made any sense.  Instead, I got a stack trace and dove headlong into devising the most complex solution imaginable – hand-rolling IL.

Sigh.