Nerdy tidbits from my life as a software engineer

Friday, October 31, 2008

Can Dynamics Solve The Problem?

At the PDC this week, the CLR team announced the addition of dynamics to the .NET framework.  I just learned about this today, reading a post off of Chris Burrows’ blog.  Fresh off the announcement of the new CLR 4.0 feature, dynamics, which look like they just might be the savoir for a lot of my mock object woes in unit tests.

I suppose, instead of doing something like this:

public ListView ListView
{
    get;
    set;
}

...

public void OnWhateverClicked(object sender, RoutedEventArgs e)
{
    ...
    int i = this.ListView.SelectedIndex;
    ...
}

You could probably do something like this:

public MyClass()
{
    this.ListView = mListView;
}

public dynamic ListView
{
    get;
    set;
}

...

public void OnWhateverClicked(object sender, RoutedEventArgs e)
{
    ...
    int i = this.ListView.SelectedIndex;
    ...
}

Everything would be identical, but since the ListView property is a dynamic, the methods that are executed on it are late-bound and therefore decided at runtime.  It should therefore be trivial to just inject some other dynamic sort into your class and therefore have a way to create mock objects on classes with non-virtual methods.  Right?

One problem: since the dynamic type is not type-safe, I don’t see how intellisense could work on it.  That would make programming against it a bit more cumbersome.

I’m trying to see if I can fiddle around with this stuff today.  It would be nice if I had a stable drop to work with, though.

Wednesday, October 29, 2008

Visual Studio’s Lack of External Unit Testing IDE

It sure is nice to have unit testing integrated with your development environment. Unless, of course, your development environment doesn’t work.  Then you’re stuck.

Which is what I am.  Stuck.  Because we use Visual Studio 2010 while we develop Visual Studio 2010 (we call it '”Dogfooding”), we often end up with builds that are, well, not so stable. Even though they pass all sorts of unit and integration tests, there are features that just don’t work.  After installing a number of drops from the last month or so and being stuck at the end of all of them, I’ve come to realize an unfortunate fact: the lack of an external testing tool for Visual Studios unit tests is a real problem.  Of course it doesn’t matter so long as Visual Studio works properly, but it is an enormous problem when Visual Studio isn’t working, because then you’re blocked from doing your job until it gets fixed in the main branch.

After a week or so of attempting either to find a drop that works or some other workaround, I decided to give up on it.  They’re going to have to fix this problem before I can do any useful work.

In the meantime, I started working on a very simple test UI.  All it does is load up a .NET assembly, search for classes that are tagged with the TestClassAttribute, and allow you to select and run a TestMethod.  It’s NUnit for Visual Studio.  Except very basic.  For now, the goal is just to have a way to select a test, run it, and debug it.  For the last week+ I haven’t been able to do that.  And so, I haven’t gotten much done as a result.  So far, I’m roughly 65% finished with the test ui.

It’s very aggravating, for sure.  But having this around for now, and in the future, will at least allow me to keep working in the event that the unit testing feature goes down again (which I think it is surely likely to).

Thursday, October 23, 2008

Interfaces and Implicit Operators

You learn something new everyday.  Today I learned that you can’t create an implicit casting operator on an interface.  I’m still puzzled as to why, but it definitely won’t work.

Here’s an example of a template class with an operator override.  This code compiles and works wonderfully, and will prove very useful in cases where it wraps objects:

/// <summary>
/// A wrapper class around type T
/// </summary>
/// <typeparam name="T">The type of object to wrap.</typeparam>
public class ObjectWrapper<T>
{
    #region Public Constructor

    /// <summary>
    /// Creates the object wrapper.
    /// </summary>
    /// <param name="wrappedObject">The object that we are wrapping</param>
    public ObjectWrapper(T wrappedObject)
    {
        this.WrappedObject = wrappedObject;
    }

    #endregion
    #region Public Properties

    /// <summary>
    /// Gets / sets the wrapped object.
    /// </summary>
    public T WrappedObject
    {
        get;
        set;
    }

    #endregion
    #region Public Methods

    /// <summary>
    /// Used to cast the wrapper as an instance of T.
    /// </summary>
    /// <param name="wrapper">The object that is wrapping T</param>
    /// <returns>An instance of T.</returns>
    public static implicit operator T(ObjectWrapper<T> wrapper)
    {
        return wrapper.WrappedObject;
    }

}

This lets us do something like:

ObjectWrapper<SomeObject> wrapper = new ObjectWrapper<SomeObject>(new SomeObject());
SomeObject o = wrapper;

This can be useful in many cases.  Having the operator overload on top of the wrapper class allows us to treat the wrapper as though it were an instance of the class it was wrapping.  However, if we define an interface:

public interface IWhatever
{
...
}

…and try the exact same thing…

ObjectWrapper<IWhatever> wrapper = new ObjectWrapper<IWhatever>(someInstance);
IWhatever whatever = wrapper;

…we’ll get a compiler error, saying: “Cannot implicitly convert type 'ObjectWrapper<IWhatever>' to 'IWhatever'. An explicit conversion exists (are you missing a cast?)”.  If we try to do the same thing, but instead of generalizing it with generics we hard-code the conversion type, we’ll get a different error:

/// <summary>
/// A class that wraps the random interface
/// </summary>
public class Wrapper
{
    /// <summary>
    /// Gets / sets the IWhatever
    /// </summary>
    public IWhatever Whatever
    {
        get;
        set;
    }

    /// <summary>
    /// An operator to convert Whatever to an IWhatever.
    /// DOES NOT COMPILE!
    /// </summary>
    /// <param name="wrapper"></param>
    /// <returns></returns>
    public static implicit operator IWhatever(Wrapper wrapper)
    {
        return wrapper.Whatever;
    }
}

This apparently is not allowed, either, but at least we get a more descriptive and helpful error message.  The compiler tells us, “user-defined conversions to or from an interface are not allowed”.  I’m impressed that it was able to catch the same problem from two very different angles.  But this particular error makes my life a bit harder, and for a reason I’m still not sure I understand.  There must be a good reason why you can’t convert to or from an interface in a casting operator.  I just don’t see it off the top of my head.

When to Blow It Up And Start Anew

I came across a blog post today that got me thinking about a predicament that I find myself in constantly.  I bet it will sound familiar.  Here’s the scenario:

You just arrived in a new job / position / division / whatever.  Somebody hands you a block of code.  It’s ugly.  It’s hackish.  It’s fragile.  It’s poorly designed.  It’s undocumented.  It’s impossible to test.  It’s difficult to debug.  It’s hard to extend.  It uses old technologies.

It also happens to be central to the company in some important way.  You can’t just stop supporting it or adding new features to it, because people depend on it every day to do their job, and it keeps the company running.

And that’s where the problem is.  As much as you’d like to throw up your hands, cry for mercy and blow it up and start anew, you’re hands are tied.  What about all the people who depend on this program today?  You can’t just pull the rug out from under their feet, can you?  And, as much as it pains you to work on this messy hogwash of bad engineering, you realize that it may not be worth the effort.  After all, it ain’t broke – why fix it?

I think the real difficulty is determining what is in the best long-term interest of your organization.  Some things can sit there and work, indefinitely, forever.  By the time it becomes a problem, some new system will likely be around that replaces your depreciated hunk-of-junk code.  That way it can die a graceful, dignified death and nobody has to suffer through a painful refactoring effort. 

The problem is that you don’t know what will happen in the future.  Maybe your tools will be needed in the future; maybe they won’t.  You don’t have the luxury of foresight.  You need to make the best decision you can based on the situation you’re in right now.  So speculating on the future is a waste of time.  You can make the right decision for today and still end up making the wrong one for tomorrow.  That doesn’t mean you made the wrong decision; it just means you were unlucky.

In situations like this, I tend to believe in detonation.  The reason why is because, assuming that your application has a long life span, it almost always pays to spend the time to fix the source of the problems rather than put the time into maintenance efforts.  I try to think of it as an investment.

The real problem, however, is convincing other people that Armageddon is the right choice.  That’s a tough sell to most managers and business folks, and I tend to do a pretty poor job of it.  How do you convince people that their software – which in their eyes works perfectly fine – needs to be tossed aside and re-written?  It’s hard for many people to see the long-term value in such a decision.  Worse, it just never seems to sit very high on people’s agenda.  They figure that your time is better spent on other things that have more tangible effects on the business’ bottom line.

Which is exactly why crappy code tends to hang around for long periods of time.  Until eventually, it collapses under its own weight, and ends up costing you more money than it would have if you had invested the time to do it properly in the first place.

Wednesday, October 22, 2008

Extracting The Last Method Called in a Delegate

In my last post I introduced you to an idea I had for mocking methods on objects that have non-virtual methods.  The idea is, given a delegate such as:

this.mAddItemForm.Call(i => i.Text = "Add New Item");

That you can inspect the delegate passed into the Call method and determine what method it was invoking.  In this case, since the code is setting the Text property, this code snippet is calling:

i.set_Text(“Add New Item");

But to determine that, we need to do some inspecting of IL.  Let’s get started by opening the assembly in ILdasm and seeing what’s going on under the hood:

.method private hidebysig static string  '<OnAddButtonClicked>b__0'(class MJB.Examples.TestApp.AddAndEditItemForm i) cil managed
{
  .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) 
  // Code size       20 (0x14)
  .maxstack  3
  .locals init ([0] string CS$1$0000,
           [1] string CS$0$0001)
  IL_0000:  ldarg.0
  IL_0001:  ldstr      "Add New Item"
  IL_0006:  dup
  IL_0007:  stloc.1
  IL_0008:  callvirt   instance void [System.Windows.Forms]System.Windows.Forms.Control::set_Text(string)
  IL_000d:  nop
  IL_000e:  ldloc.1
  IL_000f:  stloc.0
  IL_0010:  br.s       IL_0012
  IL_0012:  ldloc.0
  IL_0013:  ret
} // end of method MainForm::'<OnAddButtonClicked>b__0'

You can see that this is a pretty simple block of code.  All it’s doing is loading a string, calling set_Text, and returning the value of the string that it loaded.  Of course, this IL is disassembled.  When we inspect the actual, raw IL, we get this array:

[0]    2    byte
[1]    114    byte
[2]    29    byte
[3]    1    byte
[4]    0    byte
[5]    112    byte
[6]    37    byte
[7]    11    byte
[8]    111    byte
[9]    36    byte
[10]    0    byte
[11]    0    byte
[12]    10    byte
[13]    0    byte
[14]    7    byte
[15]    10    byte
[16]    43    byte
[17]    0    byte
[18]    6    byte
[19]    42    byte

In order to make sense of this gibberish, we need to walk through the array and look for the Callvirt OpCode.  Then, once we find it, we’ll need to resolve the operand on the instruction so that we can determine which method the statement is calling.  It just so happens that the OpCode value for callvirt is 111, and operand length of the callvirt opcode is 4 bytes.  That means that in the IL above, line 8 is the callvirt opcode, and lines 9 through 12 contains the metadata that resolves to “instance void [System.Windows.Forms]System.Windows.Forms.Control::set_Text(string)”. 

If we re-run ildasm with the /TOKENS option and inspect the delegate again, we’ll see that the metadata token for instance void [System.Windows.Forms]System.Windows.Forms.Control::set_Text(string) is 0x0A000024 (note that this value changes from assembly to assembly – it is not a constant!):

.method /*0600000D*/ private hidebysig static 
        string  '<OnAddButtonClicked>b__0'(class MJB.Examples.TestApp.AddAndEditItemForm/*02000004*/ i) cil managed
{
  .custom /*0C00001A:0A000012*/ instance void [mscorlib/*23000001*/]System.Runtime.CompilerServices.CompilerGeneratedAttribute/*0100001E*/::.ctor() /* 0A000012 */ = ( 01 00 00 00 ) 
  // Code size       20 (0x14)
  .maxstack  3
  .locals /*11000007*/ init ([0] string CS$1$0000,
           [1] string CS$0$0001)
  IL_0000:  ldarg.0
  IL_0001:  ldstr      "Add New Item" /* 7000011D */
  IL_0006:  dup
  IL_0007:  stloc.1
  IL_0008:  callvirt   instance void [System.Windows.Forms/*23000002*/]System.Windows.Forms.Control/*01000025*/::set_Text(string) /* 0A000024 */
  IL_000d:  nop
  IL_000e:  ldloc.1
  IL_000f:  stloc.0
  IL_0010:  br.s       IL_0012
  IL_0012:  ldloc.0
  IL_0013:  ret
} // end of method MainForm::'<OnAddButtonClicked>b__0'

Looking at bytes 9 through 12 again, you’ll realize that they’re in the opposite order you’d probably expect them to be.  Byte 9 happens to be the least significant bit, not the most.  We can figure this out by realizing that 36 = 0x24 and 10=0x0A.  Put these in reverse and we get 0A000024, the metadata token for the set_Text method.

Using all of this, we can now create a method that can extract the MethodInfo of the last method invoked in a dalegate that is passed to it.  This is really much easier than you may have thought:

public static MethodInfo ExtractLastMethodCalled(Delegate handler)
{
    MethodInfo method = handler.Method;
    byte[] code = method.GetMethodBody().GetILAsByteArray();

    MethodInfo lastMethodCalled = null;
    for (int i = 0; i < code.Length; i++)
    {
        // It's a little hokey to just catch this, but it's easier than
        // determing the context of this opcode.  If we can resolve the next
        // four bytes, then we're in good shape.  Otherwise, it's out of context:
        try
        {
            if ((code[i] == (byte)OpCodes.Callvirt.Value) ||
                (code[i] == (byte)OpCodes.Call.Value))
            {
                // This is the meta data address of this method:
                int address = (code[i + 1] << 0) |
                              (code[i + 2] << 8) |
                              (code[i + 3] << 16) |
                              (code[i + 4] << 24);

                lastMethodCalled = (MethodInfo)method.Module.ResolveMethod(address);
            }
        }
        catch (ArgumentException)
        {
            // Ignored
        }
    }

    if(lastMethodCalled == null)
        throw new Exception("Delegate does not invoke a method.");

    return lastMethodCalled;

}

A few things of note.  Not all calls to all methods are compiled as callvirt, so we might as well check for both flavors of OpCodes.  Second, you may be wondering why I’m wrapping things in a try / catch.  Well…that’s a poor-mans way of handling a fairly obvious problem.  What happens if a previous instruction happens to have a value equal to 111 or 40 (the OpCode value for call)?  This would be a random occurrence, but it can happen (imagine if the method was invoked with a constant int equal to 111, for instance).  In this case, the next four bytes would not actually be an operand to the callvirt OpCode, which means that the call to ResolveMethod would fail.  What we really need to do is recognize each OpCode and skip over a number of bytes equal to the operand length.  But this implementation is too lazy to do it properly.  That would require a fairly extension IL reader implementation.  For some good examples of how that’s done, check out Yiru Tangs Blog.  He’s got some good info which helped me figure a lot of this stuff out.

In any case, now that we can figure out what method is invoked in a little delegate like the one in this example, all we need to do is figure out how to extract the arguments that are being passed into that method.  That’s where the real meat of the problem lies.  Stay tuned…

Inspecting Delegates’ IL (And Why You Might Want To Do That)

If you’ve read my blog post about mocking up WPF controls in unit tests, then you might not be surprised to see that I have an interest in finding a solution to this problem.  In my previous post, I talked about one idea, which was basically to generate a number of shim libraries that allowed you to reference objects by an abstraction instead of their hard-coded types.  This approach uses inheritance and polymorphism to accomplish its goals.  Unfortunately, this approach has a somewhat serious drawback: it requires massive numbers of references to auto-generated shim assemblies.  It would be much easier if there was somehow a way to mock up virtual method calls without needing to pre-generate shims.

One approach used by Typemock is to hijack the CLR and return phony objects instead of the real ones when something is newed.  This has a number of advantages, but one large problem.  Because Typemock hooks into the CLR, it must be registered as a COM component.  This means it must be installed on whatever machine is going to run the unit tests.  For some environments, this is not a problem.  In mine, however, this is a big problem.  Builds and tests are run on many, many machines.  What would happen if we required people to install some third party software before they were able to run and pass all their unit tests?  I can only imagine how many emails would fly around from people all around my division.

So, I set out to find another solution.  And I found one.

Imagine that you defined a very simple set of extension methods and delegates:

/// <summary>
/// A method that has no return type and takes one argument.
/// </summary>
/// <typeparam name="T">The type of object in the argument.</typeparam>
/// <param name="t">The argument of the delegate.</param>
public delegate void VoidHandler<T>(T t);

/// <summary>
/// A method that returns something and takes one argument.
/// </summary>
/// <typeparam name="T">The type of the argument.</typeparam>
/// <typeparam name="U">The type of the return value.</typeparam>
/// <param name="t">the argument of the delegate.</param>
/// <returns>An instance of type U.</returns>
public delegate U ReturnHandler<T, U>(T t);

/// <summary>
/// Contains extension methods that make the syntax of using the indirection
/// framework easier.
/// </summary>
public static class ExtensionMethods
{
    /// <summary>
    /// Invokes the handler delegate.
    /// </summary>
    /// <typeparam name="T">The type of object to invoke the handler on</typeparam>
    /// <param name="t">The object instance of type T</param>
    /// <param name="handler">The handler delegate to invoke</param>
    public static void Call<T>(this T t, VoidHandler<T> handler)
    {
        handler(t);
    }

    /// <summary>
    /// Invokes the handler delegate and returns its output.
    /// </summary>
    /// <typeparam name="T">The type of object to invoke the handler on</typeparam>
    /// <typeparam name="U">The return type of the handler</typeparam>
    /// <param name="t">The object instance of type T</param>
    /// <param name="handler">The handler delegate to invoke</param>
    /// <returns>An instance of U</returns>
    public static U Call<T, U>(this T t, ReturnHandler<T, U> handler)
    {
        return handler(t);
    }

}

Now, in your code, you might have something pretty simple, like this:

public class MainForm : Form
{
    ...
    /// <summary>
    /// Called when the add button is clicked.
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private void OnAddButtonClicked(object sender, EventArgs e)
    {
        // Throw up the dialog and make sure they said yes:
        this.mSomeForm.Text = "Add New Item";
        if (this.mSomeForm.ShowDialog(this) == DialogResult.OK)
        {
            string itemValue = this.mSomeForm.ItemValue;
            this.mListBox.Items.Add(itemValue);
        }
    
    }
    ...
}

Where mSomeForm is just some random winform object that shows a modal dialog and allows some text entry.  Normally, this is exactly the sort of thing that’s impossible to unit test.  Even if you create an accessor for the MainForm class, you’re going to run into problems when you call the OnAddButtonClicked method from your unit test.  Why?  Because the Text property is a non-virtual property.  So are the ShowDialog method and the Items property on the ListBox.  That makes these objects impossible to mock in a unit test without doing all sorts of fancy subclassing.

But imagine if, instead of invoking these methods directly, you instead passed them into that Call extension method with a delegate that did it for you?  Before you ask why you might want to do that, here’s what the code would look like:

public class SomeForm : Form
{
    ...
    /// <summary>
    /// Called when the add button is clicked.
    /// </summary>
    /// <param name="sender"></param>
    /// <param name="e"></param>
    private void OnAddButtonClicked(object sender, EventArgs e)
    {
        // Throw up the dialog and make sure they said yes:
        this.mSomeForm.Call(i => i.Text = "Add New Item");
        if (this.mSomeForm.Call(i => i.ShowDialog(this)) == DialogResult.OK)
        {
            string itemValue = this.mSomeForm.Call(i => i.ItemValue);
            this.mListBox.Call(i => i.Items).Add(itemValue);
        }
    
    }
    ...
}

Looking at the code for the Call method, you can see that all this is really doing is indirecting the call to these various methods and properties.  Why would we want to do this?  Imagine if, instead of invoking the delegates directly, as we are in the code above, we instead examine the delegates’ code and determine what it’s doing?  Now imagine if we were able to set expectations on those objects in some sort of mock framework and use the Call method as a way of mocking up those method calls?  That is, instead of executing the delegate that’s passed into Call, we examine it’s IL and, if it matches our expectation, we can call something else – effectively hijacking the method call and therefore mocking it up for our unit tests.

Of course there’s a lot of complicated stuff that I’m glossing over.  Making this work requires some funky Reflection.Emit voodoo.  You might wonder how it could possibly work, if at all.  All I can say about this, for now, is that it can, in fact, work.  I have code on my machine right now that does it.  Call it a proof of concept.  Hopefully, it will end up being extremely useful in the future.

Monday, October 20, 2008

Welcome to My New Blog!

After running www.michaelbraude.com for almost three years, I finally decided to kill it and move over to a traditional blog.

A long, long time ago - back when I was still in high school - I used to run a website.  The experience I got writing HTML, JavaScript, and Perl was a big part of how I got into college.  It also gave me my first taste of programming.  Once I learned a higher level language, however, I no longer had any interest in authoring HTML.  To this day, my interest in web programming is very limited.  I just don't find it intellectually stimulating.  I prefer writing real programs using real languages; HTML + JavaScript feels like a cheap toy gone wrong.

At some point, however, I realized the importance of having a presence on the Internet.  I'm a software engineer and I have interesting things to say.  I come across interesting things at my job when I'm trying to get things done or solve a particular problem, and I like sharing these things with the rest of the community.  Running MichaelBraude.com for three years was more than worth the effort.  It served as a portfolio of work on my resume.  It gave me an opportunity to go and work for Microsoft.  And it gave me a chance to work with technologies that I didn't necessarily have a chance to work with in my day job.

So...why am I closing the website?  A few reasons.  First, I've realize that what I really enjoy running these days is my technical blog.  The rest of the website is not quite as interesting to me, nor do I think it's quite as useful to everybody else.  Second, from a professional standpoint, I realized that a blog is just as effective as a website: it still gives me an opportunity to have a presence on the Internet and potentially explore interesting opportunities, but requires less maintenance.  Third, now that I work at Microsoft, I don't need an excuse to work with the latest things.  I get that from my job.  After all, I get to work with the latest versions of Visual Studio while they're being developed.  You can't get much more bleeding edge than that!  And lastly, I decided that I wanted to take advantage of all of the free tools out there that make managing a blog easy - such as Windows Live Writer.  While it was a fun side project to write my content management system, it was a lot more work than was necessary.  Why reinvent the wheel?

So, after much deliberation, I decided to shut down the website and start focusing entirely on my technical blog.  I was able to port things over from the old website using simple cut and paste techniques, but I have to say, if it weren't for the awesome Windows Live Writer, this would have been a million times more difficult.

So stay tuned for more nerd talk as I write it!