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.
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).
I had the same problem. I figured out that my assembly, which is loaded by the main program, had some references with "Copy Local" set to true. These local copies of references were looking for other references in the same folder, which did not exist because the "Copy Local" of other references was set to false. After the deletion of the "accidentally" copied references the error was gone because the main program was set to look for correct locations of references. Apparently the local copies of the references screwed up the sequence of calling because these local copies were used instead of the original ones present in the main program.
The take home message is that this error appears due to the missing link to load the required assembly.
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
.The interface definition gets the following signature:
Note that the C++ type
long
maps toSystem.Int32
(or simplyint
in C#). It is the somewhat obscuremodopt
that is causing the problem as stated by Ayende Rahien on the Rhino Mocks mailing list .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 received this error after a recent windows update. I had a service class set to inherit from an interface. The interface contained a signature that returned a ValueTuple, a fairly new feature in C#.
All I can guess is that the windows update installed a new one, but even explicitly referencing it, updating binding redirects, etc...The end result was just changing the signature of the method to something "standard" I guess you could say.
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.