TypeLoadException says 'no implementation', but it is implemented

I've got a very weird bug on our test machine. The error is:

System.TypeLoadException: Method 'SetShort' in type 'DummyItem' from assembly 'ActiveViewers (...)' does not have an implementation.

I just can't understand why. SetShort is there in the DummyItem class, and I've even recompiled a version with writes to the event log just to make sure that it's not a deployment/versioning issue. The weird thing is that the calling code doesn't even call the SetShort method.

Solution 1:

NOTE - If this answer doesn't help you, please take the time to scroll down through the other answers that people have added since.

Short answer

This can happen if you add a method to an interface in one assembly, and then to an implementing class in another assembly, but you rebuild the implementing assembly without referencing the new version of the interface assembly.

In this case, DummyItem implements an interface from another assembly. The SetShort method was recently added to both the interface and the DummyItem - but the assembly containing DummyItem was rebuilt referencing the previous version of the interface assembly. So the SetShort method is effectively there, but without the magic sauce linking it to the equivalent method in the interface.

Long answer

If you want to try reproducing this, try the following:

Create a class library project: InterfaceDef, add just one class, and build:

public interface IInterface
{
    string GetString(string key);
    //short GetShort(string key);
}

Create a second class library project: Implementation (with separate solution), copy InterfaceDef.dll into project directory and add as file reference, add just one class, and build:

public class ImplementingClass : IInterface
{
    #region IInterface Members
    public string GetString(string key)
    {
        return "hello world";
    }

    //public short GetShort(string key)
    //{
    //    return 1;
    //}
    #endregion
}

Create a third, console project: ClientCode, copy the two dlls into the project directory, add file references, and add the following code into the Main method:
```
 IInterface test = new ImplementingClass();
 string s = test.GetString("dummykey");
 Console.WriteLine(s);
 Console.ReadKey();
```
Run the code once, the console says "hello world"
Uncomment the code in the two dll projects and rebuild - copy the two dlls back into the ClientCode project, rebuild and try running again. TypeLoadException occurs when trying to instantiate the ImplementingClass.

Solution 2:

In addition to what the asker's own answer already stated, it may be worth noting the following. The reason this happens is because it is possible for a class to have a method with the same signature as an interface method without implementing that method. The following code illustrates that:

public interface IFoo
{
    void DoFoo();
}

public class Foo : IFoo
{
    public void DoFoo() { Console.WriteLine("This is _not_ the interface method."); }
    void IFoo.DoFoo() { Console.WriteLine("This _is_ the interface method."); }
}

Foo foo = new Foo();
foo.DoFoo();               // This calls the non-interface method
IFoo foo2 = foo;
foo2.DoFoo();              // This calls the interface method

Solution 3:

I got this when my application didn't have a reference to another assembly defining a class that the method in the error message used. Running PEVerify gave more helpful error: "The system cannot find the file specified."

Solution 4:

I came across the same message and here is what we have found: We use third party dlls in our project. After a new release of those was out we changed our project to point to the new set of dlls and compiled successfully.

The exception was thrown when I tried to instatiate one of the their interfaced classes during run time. We made sure that all the other references were up to date, but still no luck. We needed a while to spot (using the Object Browser) that the return type of the method in the error message was a completely new type from a new, unreferenced assembly.

We added a reference to the assembly and the error disappeared.

The error message was quite misleading, but pointed more or less to the right direction (right method, wrong message).
The exception ocurred even though we did not use the method in question.
Which leads me to the question: If this exception is thrown in any case, why does the compiler not pick it up?

Solution 5:

I received this error in the following scenario.

Both Assemblies A and B referenced System.Web.Mvc Version 3.0.0.0
Assembly A referenced Assembly B and had classes which implemented interfaces from Assembly B with methods which returned classes from System.Web.Mvc.
Assembly A upgraded to System.Web.Mvc Version 4.0.0.0
Assembly C ran the code below (FertPin.Classes.Contact was contained in Assembly A):

var target = Assembly.GetAssembly(typeof(FertPin.Classes.Contact));

The fix for me was upgrading the System.Web.Mvc reference in Assembly B to 4.0.0.0. Seems obvious now!

Thanks to the original poster!