views:

835

answers:

2

Using Visual Studio 2008 / C# / VS Unit Testing.

I have a very straightforward extension method, that will tell me if an object is of a specific type:

public static bool IsTypeOf<T, O>(this T item, O other)
{
    if (!(item.GetType() is O))
        return false;
    else
        return true;
}

It would be called like:

Hashtable myHash = new Hashtable();
bool out = myHash.IsTypeOf(typeof(Hashtable));

The method works just fine when I run the code in debug mode or if I debug my unit tests. However, the minute I just run all the unit tests in context, I mysteriously get a MissingMethodException for this method. Strangely, another extension method in the same class has no problems.

I am leaning towards the problem being something other than the extension method itself. I have tried deleting temporary files, closing/reopening/clean/rebuilding the solution, etc. So far nothing has worked.

Has anyone encountered this anywhere?

Edit: This is a simplified example of the code. Basically, it is the smallest reproducible example that I was able to create without the baggage of the surrounding code. This individual method also throws the MissingMethodException in isolation when put into a unit test, like above. The code in question does not complete the task at hand, like Jon has mentioned, it is more the source of the exception that I am currently concerned with.

Solution: I tried many different things, agreeing with Marc's line of thinking about it being a reference issue. Removing the references, cleaning/rebuilding, restarting Visual Studio did not work. Ultimately, I ended up searching my hard drive for the compiled DLL and removed it from everywhere that did not make sense. Once removing all instances, except the ones in the TestResults folder, I was able to rebuild and rerun the unit tests successfully.

As to the content of the method, it was in unit testing that I discovered the issue and was never able to get the concept working. Since O is a RunTimeType, I do not seem to have much access to it, and had tried to use IsAssignableFrom() to get the function returning correctly. At this time, this function has been removed from my validation methods to be revisited at another time. However, prior to removing this, I was still getting the original issue that started this post with numerous other methods.

Post-solution: The actual method was not as complex as I was making it out to be. Here is the actual working method:

public static void IsTypeOf<T>(this T item, Type type)
{
    if (!(type.IsAssignableFrom(item.GetType())))
        throw new ArgumentException("Invalid object type");
}

and the unit test to verify it:

[TestMethod]
public void IsTypeOfTest()
{
    Hashtable myTable = new Hashtable();
    myTable.IsTypeOf(typeof(Hashtable));

    try
    {
        myTable.IsTypeOf(typeof(System.String));
        Assert.Fail("Type comparison should fail.");
    }
    catch (ArgumentException)
    { }
}
A: 
shahkalpesh
I am unable to get the compound constraint to work. It results in a syntax error. I'll keep fiddling with it. The class that it is in is called "ObjectValidationExtensions" in the root assembly of the application.
joseph.ferris
+4  A: 

Usually, a MissingMethodException means that you are loading a different version of the dll to the one you referenced during build, and the actual dll you are loading (at run-time) doesn't have the method the compiler found (at compile-time).

Check that you haven't somehow got various versions of the dll referenced by different projects. It could be that when you run it in debug mode, some other code makes the correct dll load first, but when running in-context, this other code doesn't run - so the incorrect version loads instead.

This would apply doubly if the failing method was added recently, so might not be in the older version referenced.

If you are using full assembly versioning, you might be able to watch the debug output to see exactly which assembly loads.

Marc Gravell
Marc, that makes sense. I am going to try creating a new project and pulling the class in to it, since the references seem to be fine via manual inspection. I'll let you know how it turns out.
joseph.ferris
Ultimately, it was somehow picking up a reference from a compiled version of the assembly from somewhere else, despite having been added as a Project Reference. Thanks for the help!
joseph.ferris