TypeLoadException says 'no implementation', but it is implemented

Question

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:

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

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

2. 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
   }
   

3. 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();
   

4. Run the code once, the console says "hello world"

5. 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.

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

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."

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?

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!

The other time you can get this error is if you have an incorrect version of a signed assembly. It's not the normal symptom for this cause, but here was the scenario where I got it

• an asp.net project contains assembly A and assembly B, B is strongly named

• assembly A uses Activator.CreateInstance to load assembly C (i.e. there is no reference to C which is built separately)

• C was built referencing an older version of assembly B than is currently present

hope that helps someone - it took me ages to figure this out.