TypeLoadException says no implementation but it is implemented

Question

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

User · Answer

In my case I had previously referenced a mylib project in a sibling folder outside of the repo - let's call that v1.0.

|-- myrepo
|    |-- consoleApp
|    |-- submodules
|         |-- mylib (submoduled v2.0)
|-- mylib (stale v1.0)

Later I did it properly and used it via a git submodule - lets call that v2.0. One project consoleApp however wasn't updated properly. It was still referencing the old v1.0 project outside of my git project.

Confusingly, even though the *.csproj was plainly wrong and pointing to v1.0, the Visual Studio IDE showed the path as the v2.0 project! F12 to inspect the interface and class went to the v2.0 version too.

The assembly placed into the bin folder by the compiler was the v1.0 version, hence the headache.

That fact that the IDE was lying to me made it extra hard to realise the error.

Solution: Deleted project references from ConsoleApp and readded them.

General Tip: Recompile all assemblies from scratch (where possible, can't for nuget packages of course) and check datetime stamps in bin\debug folder. Any old dated assemblies are your problem.

User · Answer

I got this in a WCF service due to having an x86 build type selected  causing the bins 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

User · Answer

In my case  I was attempting to use TypeBuilder to create a type  TypeBuilder CreateType threw this exception   I eventually realized that I needed to add MethodAttributes Virtual to the attributes when calling TypeBuilder DefineMethod for a method that helps implements an interface   This is because without this flag  the method does not implement the interface  but rather a new method with the same signature instead  even without specifying MethodAttributes NewSlot

User · 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

User · Answer

Our problem solved with updating windows  Our web application is on  Net 4 7 1 and c  7 0  As we tested in different windowses  we understood that the problem will be solved by updating windows  Indeed  the problem was seen in windows 10  version 1703  and also in a windows server 2012 not updated in last year   After updating both of them  the problem was solved  In fact  the asp net minor version the third part of the clr dll version in C  Windows Microsoft NET Framework64 v4 0 30319   was changed a bit after the update

User · Answer

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

User · Answer

I keep coming back to this    Many of the answers here do a great job of explaining what the problem is but not how to fix it   The solution to this is to manually delete the bin files in your projects published directory  It will clean up all the references and force the project to use the latest DLLs   I don t suggest using the publish tools Delete function because this tends to throw off IIS

User · Answer

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

User · Answer

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

User · 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

User · 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

User · Answer

As an addendum  this can also occur if you update a nuget package that was used to generate a fakes assembly  Say you install V1 0 of a nuget package and create a fakes assembly  fakeLibrary 1 0 0 0 Fakes   Next  you update to the newest version of the nuget package  say v1 1 which added a new method to an interface  The Fakes library is still looking for v1 0 of the library  Simply remove the fake assembly and regenerate it  If that was the issue  this will probably fix it

User · Answer

I encountered this error in a context where I was using Autofac and a lot of dynamic assembly loading   While performing an Autofac resolution operation  the runtime would fail to load one of the assemblies  The error message complained that Method  MyMethod  in type  MyType  from assembly  ImplementationAssembly  does not have an implementation  The symptoms occurred when running on a Windows Server 2012 R2 VM  but did not occur on Windows 10 or Windows Server 2016 VMs   ImplementationAssembly referenced System Collections Immutable 1 1 37  and contained implementations of a IMyInterface lt T1 T2 gt  interface  which was defined in a separate DefinitionAssembly  DefinitionAssembly referenced System Collections Immutable 1 1 36    The methods from IMyInterface lt T1 T2 gt  which were  not implemented  had parameters of type IImmutableDictionary lt TKey  TRow gt   which is defined in System Collections Immutable   The actual copy of System Collections Immutable found in the program directory was version 1 1 37  On my Windows Server 2012 R2 VM  the GAC contained a copy of System Collections Immutable 1 1 36  On Windows 10 and Windows Server 2016  the GAC contained a copy of System Collections Immutable 1 1 37  The loading error only occurred when the GAC contained the older version of the DLL   So  the root cause of the assembly load failure was the mismatching references to System Collections Immutable  The interface definition and implementation had identical-looking method signatures  but actually depended on different versions of System Collections Immutable  which meant that the runtime did not consider the implementation class to match the interface definition    Adding the following binding redirect to my application config file fixed the issue    lt dependentAssembly gt           lt assemblyIdentity name  System Collections Immutable  publicKeyToken  b03f5f7f11d50a3a  culture  neutral    gt           lt bindingRedirect oldVersion  0 0 0 0-1 1 37 0  newVersion  1 1 37 0    gt   lt  dependentAssembly gt

User · Answer

I get this error today  My problem was - do not doing in TFS get latest version  In server was dll with interface whic one of methods was modified  I worked with an old one - in my PC its works  How to fix  get latest  rebuild

User · Answer

I got this error because I had a class in an assembly  C  which was on version 4 5 of the framework  implementing an interface in assembly  A  which was on version 4 5 1 of the framework and serving as the base class to assembly  B  which was also on version 4 5 1 of the framework  The system threw the exception while trying to load assembly  B   Additionally  I had installed some nuget packages targeting  net 4 5 1 on all three assemblies  For some reason  even though the nuget references were not showing in assembly  B   it was building successfully   It turned out that the real issue was that the assemblies were referencing different versions of a nuget package that contained the interface and the interface signature had changed between versions

User · Answer

The solution for me was related to the fact that the project that was implementing the interface had the property  quot Register for COM Interop quot  set   Unchecking this option resolved the issue for me

User · Answer

Another possibility is a mixture of release and debug builds in the dependencies   For example  Assembly A depends on Assembly B  A was built in Debug mode while the copy of B in GAC was built in Release mode  or vice versa

User · Answer

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

User · 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    lt  xml version  1 0  encoding  utf-8    gt   lt configuration gt     lt runtime gt       lt assemblyBinding xmlns  urn schemas-microsoft-com asm v1  gt         lt dependentAssembly gt           lt assemblyIdentity name  System Web Helpers  publicKeyToken  31bf3856ad364e35    gt           lt bindingRedirect oldVersion  1 0 0 0-3 0 0 0  newVersion  3 0 0 0    gt         lt  dependentAssembly gt         lt dependentAssembly gt           lt assemblyIdentity name  System Web WebPages  publicKeyToken  31bf3856ad364e35    gt           lt bindingRedirect oldVersion  0 0 0 0-3 0 0 0  newVersion  3 0 0 0    gt         lt  dependentAssembly gt         lt dependentAssembly gt           lt assemblyIdentity name  System Web Mvc  publicKeyToken  31bf3856ad364e35    gt           lt bindingRedirect oldVersion  0 0 0 0-5 1 0 0  newVersion  5 1 0 0    gt         lt  dependentAssembly gt       lt  assemblyBinding gt     lt  runtime gt   lt  configuration gt

User · Answer

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

User · Answer

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

User · Answer

I had this error when my integration test project was trying to load a DLL which didn t contain dependency resolution for an interface    Integration Test Project  references Main Project but not StructureMap   Main Project  references StructureMap project - uses Interface in class constructor  StructureMap Project  IoC - For   Use       This caused the error to be thrown because it couldn t find the concrete implementation  I excluded the DLL in my test configuration and the error disappeared

User · 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

User · Answer

Here s my take on this error   Added an extern method  but my paste was faulty   The DllImportAttribute got put on a commented out line        lt returns gt  removed for brevity lol  lt  returns gt  DllImport  user32 dll      return  MarshalAs UnmanagedType Bool   public static extern bool IsWindowVisible IntPtr hWnd     Ensuring the attribute was actually included in source fixed the issue

User · Answer

Yet another way to get this   class GenericFoo lt T gt      class ConcreteFoo   GenericFoo lt ClassFromAnotherAssembly gt       Code in an assembly that doesn t reference the assembly of ClassFromAnotherAssembly   var foo   new ConcreteFoo      kaboom   This happened to me when ClassFromAnotherAssembly was ValueTuple

User · Answer

I have yet another esoteric solution to this error message   I upgraded my target framework from  Net 4 0 to 4 6  and my unit test project was giving me the  System TypeLoadException   does not have an implementation  error when I tried to build   It also gave a second error message about the same supposedly non-implemented method that said  The  BuildShadowTask  task failed unexpectedly    None of the advice here seemed to help  so I searched for  BuildShadowTask   and found a post on MSDN which led me to use a text editor to delete these lines from the unit test project s csproj file    lt ItemGroup gt     lt Shadow Include  Test References MyProject accessor    gt   lt  ItemGroup gt    After that  both errors went away and the project built

User · 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

User · 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

User · Answer

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

User · Answer

I faced almost same issue  I was scratching my head what is causing this error  I cross checked  all the methods were implemented    On Googling I got this link among other  Based on  Paul McLink comment  This two steps resolved the issue    Restart Visual Studio Clean  Build  Rebuild    and the error gone   Restart VS Plugin  Thanks Paul     Hope this helps someone who come across this error

User · 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    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  Close Visual Studio  In my case Visual Studio terminated with a violation exception and aborted  Restart Visual Studio  Now everything is running smoothly

User · 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

User · Answer

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

User · 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   public    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

User · 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

User · Answer

I ran into this and only my local machine was having the problem  No other developers in our group nor my VM had the problem   In the end it seemed to be related to a  targeting pack  Visual Studio 2017   Open the Visual Studio Installer Select Modify Go to the second top tab  Individual Components  See what Frameworks and Targeting packs you have selected  I did not have the two newest targeting packs selected  I also noticed I did not have  Advanced ASP NET features  selected and the other machines did  Selected and installed the new items and it is all good now

User · Answer

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     GetAssemblies       ToList       SelectMany  s   gt  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

User · Answer

Just to add my experience as it has not been covered in other answers    I got this problem when running unit tests in MsTest    The classes under test were in a signed assembly    A different version of this assembly happened to be in the GAC  but with the same assembly version number    Dependency resolution algorithm for strong named assemblies is slightly different to non-signed as the GAC is checked first   So MsTest was picking up the GAC d assembly rather than using the one from the bin folder  and trying to run the tests against it  which was obviously not working    Solution was to remove the GAC d assembly    Note  the clue for me was this was not happening on the build server when the tests were run  because the build would compile the assemblies with a new assembly version number  This meant that older versions of the assembly in the GAC would not be picked up    Also  I found a potential workaround here  if you cannot for some reason access the GAC  https   johanleino wordpress com 2014 02 20 workaround-for-unit-testing-code-that-reside-in-the-gac

[c#] TypeLoadException says 'no implementation', but it is implemented

Examples related to c#

Examples related to .net

Examples related to fusion

Examples related to typeloadexception