Take the 2-minute tour ×




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.

share|improve this question
I love how your shared your experience with the community to help us all, and even encouraged us to read the other answers too, thank you. Sadly, none of suggestions worked for me. Want to know what did end up working for me? Restarting Visual Studio. Why did I not try that first? –  Paul McLean Jun 4 at 1:10
Thanks Paul, after reading your comment I've tried that one first. Worked like a charm :-) –  Jan_V Jun 12 at 12:45

19 Answers 19

up vote 127 down vote accepted


Short answer



Long answer

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


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

    public class ImplementingClass : IInterface
        #region IInterface Members
        public string GetString(string key)
            return "hello world";
    //public short GetShort(string key)
    //    return 1;

     IInterface test = new ImplementingClass();
     string s = test.GetString("dummykey");


share|improve this answer
Nice example of answering your own question to persist experience. –  Michael Petrotta Jun 4 '09 at 6:02
You might need to add that the Console app should be rebuilt with the new DLLs as reference. Merely copying the DLL won't work and that could be due to version mismatch (i.e after you compile the source DLL the version will change). Is that fair understanding? –  shahkalpesh Jun 4 '09 at 6:04
@shahkalpesh good point - for me 'running again' implied F5. I've updated the answer. Of course all this wouldn't have happened with a decent source control tool, but don't get me started on that subject... –  Benjol Jun 4 '09 at 6:21
Hmm, it looks like Microsoft's error message has an error in it - it's saying that a method of class "DummyItem" doesn't have an implementation, which is patently false.... really the problem is that a method of the interface isn't implemented BY DummyItem. –  Qwertie Jun 13 '10 at 4:16
any good final solution about it ? What solution was Microsoft recommended ? –  Kiquenet Sep 18 '12 at 18:27

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
share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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?
share|improve this answer
That IS weird.. –  Benjol May 6 '10 at 4:41

I received this error in the following scenario.

  • Both Assemblies A and B referenced System.Web.Mvc Version
  • 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
  • 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 Seems obvious now!

Thanks to the original poster!

share|improve this answer
I had something similar but the other way round with versions. One method, targetting .NET 2, returned a type from v2 of System.Windows.Forms. Its overridden implementation in a .NET 4-targetted assembly returned the same type but from v4 of System.Windows.Forms. It compiled fine but ReflectionOnlyLoadFrom didn't like it. –  Stephen Hewlett Nov 25 '12 at 3:44
I had a similar problem caused by loading types which targeted .NET2 into a ReflectionOnly context of a .NET4 application. I worked around the problem by redirecting all assembly requests of .NET2 core assemblies to their .NET4 counterparts in the AppDomain.ReflectionOnlyAssemblyResolve event. –  Chaquotay Jul 29 '13 at 12:49

I had this error too, it was caused by an Any CPU exe referencing Any CPU assemblies that in turn referenced an x86 assembly.

The exception complained about a method on a class in MyApp.Implementations (Any CPU), which derived MyApp.Interfaces (Any CPU), but in fuslogvw.exe I found a hidden 'attempt to load program with an incorrect format' exception from MyApp.CommonTypes (x86) which is used by both.

share|improve this answer

I got this with a "diamond" shaped project dependency:

  • Project A uses Project B and Project D
  • Project B uses Project D

I recompiled project A but not Project B, which allowed Project B to "inject" the old version of the Project D dll

share|improve this answer
Yeah, I like to think of that as the Renault problem –  Benjol Sep 23 '10 at 11:13

I encountered this when I renamed a project (and the assembly name), which was depended upon by an ASP.NET project. Types in the web project implemented interfaces in the dependent assembly. Despite executing Clean Solution from the Build menu, the assembly with the previous name remained in the bin folder, and when my web project executed

var types = AppDomain.CurrentDomain.
   SelectMany( s => s.GetTypes() /* exception thrown in this call */ )

the above exception was thrown, complaining that interface methods in the implementing web types were not actually implemented. Manually deleting the assembly in the web project's bin folder resolved the problem.

share|improve this answer

I just upgraded a solution from MVC3 to MVC5, and started receiving the same exception from my Unit test project.

Checked all the references looking for old files, eventualy discovered I needed to do some bindingRedirects for Mvc, in my unit test project.

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <bindingRedirect oldVersion="" newVersion="" />
        <bindingRedirect oldVersion="" newVersion="" />
        <bindingRedirect oldVersion="" newVersion="" />
share|improve this answer

Another explanation for this type of problem involving managed C++.

If you try to stub an interface defined in an assembly created using managed C++ that has a special signature you will get the exception when the stub is created.

This is true for Rhino Mocks and probably any mocking framework that uses System.Reflection.Emit.

public interface class IFoo {
  void F(long bar);

public ref class Foo : public IFoo {
  virtual void F(long bar) { ... }

The interface definition gets the following signature:

void F(System.Int32 modopt(IsLong) bar)

Note that the C++ type long maps to System.Int32 (or simply int in C#). It is the somewhat obscure modopt that is causing the problem as stated by Ayende Rahien on the Rhino Mocks mailing list .

share|improve this answer
I had this error when I used the datatype System::Byte. I changed the signature to accept an unsigned short and the sky was blue again. –  Krishter Feb 17 '12 at 10:18

I also ran into this problem while running my unittests. The application ran fine and with no errors. The cause of the problem in my case was that I had turned off the building of the test projects. Reenabling the building of my testprojects solved the issues.

share|improve this answer

I got this in a WCF service due to having an x86 build type selected, causing the bisn to live under bin\x86 instead of bin. Selecting Any CPU caused the recompiled DLLs to go to the correct locations (I wont go into detail as to how this happened in the first place).

share|improve this answer

I also got this error when I had previously enabled Code Coverage during unit testing for one of the assemblies. For some reason Visual Studio "buffered" the old version of this particular DLL even though I had updated it to implement a new version of the interface. Disabling Code Coverage got rid of the error.

share|improve this answer

This error can also be caused if an assembly is loaded using Assembly.LoadFrom(String) and is referencing an assembly that was already loaded using Assembly.Load(Byte[]).

For instance you have embedded the main application's referenced assemblies as resources but your app loads plug-ins from a specific folder.

Instead of using LoadFrom you should use Load. The following code will do the job:

private static Assembly LoadAssemblyFromFile( String filePath )
    using( Stream stream = File.OpenRead( filePath ) )
        if( !ReferenceEquals( stream, null ) )
            Byte[] assemblyData = new Byte[stream.Length];
            stream.Read( assemblyData, 0, assemblyData.Length );
            return Assembly.Load( assemblyData );
    return null;
share|improve this answer
any full source code sample ? –  Kiquenet Sep 18 '12 at 18:25

I saw this in Visual Studio Pro 2008 when two projects built assemblies with the same name, one a class lib SDF.dll, and one that referenced the lib with assembly name sdf.exe. When I changed the name of the referencing assembly, the exception went away

share|improve this answer

In my case it helped to reset the WinForms Toolbox.

I got the exception when opening a Form in the designer; however, compiling and running the code was possible and the code behaved as expected. The exception occurred in a local UserControl implementing an interface from one of my referenced libraries. The error emerged after this library was updated.

This UserControl was listed in the WinForms Toolbox. Probably Visual Studio kept a reference on an outdated version of the library or was caching an outdated version somewhere.

Here is how I recovered from this situation:

  1. Right click on the WinForms Toolbox and click on Reset Toolbox in the context menu. (This removes custom items from the Toolbox).
    In my case the Toolbox items were restored to their default state; however, the Pointer-arrow was missing in the Toolbox.
  2. Close Visual Studio.
    In my case Visual Studio terminated with a violation exception and aborted.
  3. Restart Visual Studio.
    Now everything is running smoothly.
share|improve this answer

FWIW, I got this when there was a config file that redirected to a non-existent version of a referenced assembly. Fusion logs for the win!

share|improve this answer

This simply means that the implementation project is out of date in my cases. The DLL containing the interface was rebuilt but the implementation dll was stale.

share|improve this answer

Your Answer


