TypeLoadException dit «pas d'implémentation», mais il est implémenté

J'ai un bug très bizarre sur notre machine de test. L'erreur est:

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

Je ne comprends tout simplement pas pourquoi. SetShortest là dans la DummyItemclasse, et j'ai même recompilé une version avec des écritures dans le journal des événements juste pour m'assurer qu'il ne s'agit pas d'un problème de déploiement / versioning. La chose étrange est que le code appelant n'appelle même pas la SetShortméthode.

REMARQUE - Si cette réponse ne vous aide pas, veuillez prendre le temps de faire défiler les autres réponses que les gens ont ajoutées depuis.

Réponse courte

Cela peut se produire si vous ajoutez une méthode à une interface dans un assembly, puis à une classe d'implémentation dans un autre assembly, mais vous reconstruisez l'assembly d'implémentation sans référencer la nouvelle version de l'assembly d'interface.

Dans ce cas, DummyItem implémente une interface à partir d'un autre assembly. La méthode SetShort a été récemment ajoutée à la fois à l'interface et au DummyItem - mais l'assembly contenant DummyItem a été reconstruit en faisant référence à la version précédente de l'assembly d'interface. Ainsi, la méthode SetShort est effectivement là, mais sans la sauce magique qui la relie à la méthode équivalente dans l'interface.

Longue réponse

Si vous souhaitez essayer de reproduire cela, essayez ce qui suit:

1. Créez un projet de bibliothèque de classes: InterfaceDef, ajoutez une seule classe et créez:

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

2. Créez un projet de bibliothèque de deuxième classe: implémentation (avec une solution distincte), copiez InterfaceDef.dll dans le répertoire du projet et ajoutez comme référence de fichier, ajoutez une seule classe et générez:

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

3. Créez un troisième projet de console: ClientCode, copiez les deux dll dans le répertoire du projet, ajoutez des références de fichier et ajoutez le code suivant dans la méthode Main:

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

4. Exécutez le code une fois, la console dit "bonjour le monde"

5. Décommentez le code dans les deux projets de DLL et reconstruisez - copiez les deux DLL dans le projet ClientCode, reconstruisez et essayez de relancer. TypeLoadException se produit lors de la tentative d'instanciation de la classe ImplementingClass.

En plus de ce que la réponse du demandeur a déjà indiqué, il peut être utile de noter ce qui suit. La raison pour laquelle cela se produit est qu'il est possible pour une classe d'avoir une méthode avec la même signature qu'une méthode d'interface sans implémenter cette méthode. Le code suivant illustre cela:

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

J'ai obtenu cela lorsque mon application n'avait pas de référence à un autre assembly définissant une classe utilisée par la méthode du message d'erreur. L'exécution de PEVerify a donné une erreur plus utile: "Le système ne peut pas trouver le fichier spécifié."

Je suis tombé sur le même message et voici ce que nous avons trouvé: Nous utilisons des DLL tierces dans notre projet. Après une nouvelle version de ceux-ci, nous avons changé notre projet pour pointer vers le nouvel ensemble de DLL et compilé avec succès.

L'exception a été levée lorsque j'ai essayé d'instaurer l'une de leurs classes interfacées pendant l'exécution. Nous nous sommes assurés que toutes les autres références étaient à jour, mais toujours pas de chance. Nous avions besoin d'un certain temps pour constater (à l'aide de l'Explorateur d'objets) que le type de retour de la méthode dans le message d'erreur était un type complètement nouveau à partir d'un nouvel assembly non référencé.

Nous avons ajouté une référence à l'assemblage et l'erreur a disparu.

• Le message d'erreur était assez trompeur, mais pointait plus ou moins dans la bonne direction (bonne méthode, mauvais message).
• L'exception s'est produite même si nous n'avons pas utilisé la méthode en question.
• Ce qui m'amène à la question: si cette exception est levée dans tous les cas, pourquoi le compilateur ne la prend-elle pas?

J'ai reçu cette erreur dans le scénario suivant.

• Les assemblys A et B ont référencé System.Web.Mvc version 3.0.0.0
• L'assembly A faisait référence à l'assembly B et avait des classes qui implémentaient des interfaces de l'assembly B avec des méthodes qui renvoyaient des classes de System.Web.Mvc.
• Assembly A mis à niveau vers System.Web.Mvc version 4.0.0.0
• L'assembly C a exécuté le code ci-dessous (FertPin.Classes.Contact était contenu dans l'assembly A):

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

Le correctif pour moi consistait à mettre à niveau la référence System.Web.Mvc de l'assembly B vers 4.0.0.0. Semble évident maintenant!

Merci à l'affiche originale!

L'autre fois que vous pouvez obtenir cette erreur, c'est si vous avez une version incorrecte d'un assembly signé. Ce n'est pas le symptôme normal de cette cause, mais voici le scénario où je l'ai eu

• un projet asp.net contient l'assembly A et l'assembly B, B est fortement nommé

• l'assembly A utilise Activator.CreateInstance pour charger l'assembly C (c'est-à-dire qu'il n'y a aucune référence à C qui est construit séparément)

• C a été construit en référence à une version plus ancienne de l'assemblage B que celle actuellement présente

J'espère que cela aide quelqu'un - il m'a fallu des siècles pour comprendre cela.

J'avais aussi cette erreur, elle était causée par un exe Any CPU référençant tous les assemblys CPU qui à leur tour référençaient un assemblage x86.

L'exception se plaignait d'une méthode sur une classe dans MyApp.Implementations (Any CPU), qui dérivait MyApp.Interfaces (Any CPU), mais dans fuslogvw.exe j'ai trouvé une exception "tentative de chargement de programme avec un format incorrect" de MyApp .CommonTypes (x86) qui est utilisé par les deux.

Je reviens toujours à ce sujet ... Beaucoup de réponses ici expliquent très bien quel est le problème, mais pas comment le résoudre.

La solution à cela consiste à supprimer manuellement les fichiers bin dans le répertoire publié de vos projets. Il nettoiera toutes les références et forcera le projet à utiliser les dernières DLL.

Je ne suggère pas d'utiliser la fonction Supprimer des outils de publication, car cela a tendance à désactiver IIS.

J'ai encore une autre solution ésotérique à ce message d'erreur. J'ai mis à niveau mon framework cible de .Net 4.0 vers 4.6, et mon projet de test unitaire me donnait l'erreur "System.TypeLoadException ... n'a pas d'implémentation" lorsque j'ai essayé de construire. Il a également donné un deuxième message d'erreur à propos de la même méthode supposée non implémentée qui a déclaré "La tâche 'BuildShadowTask' a échoué de manière inattendue." Aucun des conseils ici ne semblait aider, j'ai donc recherché "BuildShadowTask" et trouvé un message sur MSDN qui m'a amené à utiliser un éditeur de texte pour supprimer ces lignes du fichier csproj du projet de test unitaire.

<ItemGroup>
  <Shadow Include="Test References\MyProject.accessor" />
</ItemGroup>

Après cela, les deux erreurs ont disparu et le projet a été construit.

J'ai rencontré cette erreur dans un contexte où j'utilisais Autofac et beaucoup de chargement d'assemblage dynamique.

Lors de l'exécution d'une opération de résolution Autofac, le runtime ne parviendrait pas à charger l'un des assemblys. Le message d'erreur s'est plaint de cela Method 'MyMethod' in type 'MyType' from assembly 'ImplementationAssembly' does not have an implementation. Les symptômes se sont produits lors de l'exécution sur une machine virtuelle Windows Server 2012 R2, mais ne se sont pas produits sur les machines virtuelles Windows 10 ou Windows Server 2016.

ImplementationAssemblyréférencé System.Collections.Immutable1.1.37, et contenait des implémentations d'une IMyInterface<T1,T2>interface, qui était définie dans un document séparé DefinitionAssembly. DefinitionAssemblyréférencé System.Collections.Immutable1.1.36.

Les méthodes à partir IMyInterface<T1,T2>desquelles n'étaient "pas implémentées" avaient des paramètres de type IImmutableDictionary<TKey, TRow>, qui est défini dans System.Collections.Immutable.

La copie réelle de System.Collections.Immutabletrouvée dans le répertoire du programme était la version 1.1.37. Sur ma machine virtuelle Windows Server 2012 R2, le GAC contenait une copie du System.Collections.Immutable1.1.36. Sur Windows 10 et Windows Server 2016, le GAC contenait une copie du System.Collections.Immutable1.1.37. L'erreur de chargement ne s'est produite que lorsque le GAC contenait l'ancienne version de la DLL.

Ainsi, la cause première de l'échec de la charge de l'assembly était les références incompatibles avec System.Collections.Immutable. La définition et l'implémentation de l'interface avaient des signatures de méthode d'apparence identique, mais dépendaient en fait de différentes versions de System.Collections.Immutable, ce qui signifiait que le runtime ne considérait pas la classe d'implémentation comme correspondant à la définition de l'interface.

L'ajout de la redirection de liaison suivante à mon fichier de configuration d'application a résolu le problème:

<dependentAssembly>
        <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.1.37.0" newVersion="1.1.37.0" />
</dependentAssembly>

J'ai obtenu ceci avec une dépendance de projet en forme de "diamant":

• Le projet A utilise le projet B et le projet D
• Le projet B utilise le projet D

J'ai recompilé le projet A mais pas le projet B, ce qui a permis au projet B «d'injecter» l'ancienne version de la DLL du projet D

J'ai rencontré cela lorsque j'ai renommé un projet (et le nom de l'assembly), dont dépendait un projet ASP.NET. Les types du projet Web ont implémenté des interfaces dans l'assembly dépendant. Malgré l'exécution de Clean Solution à partir du menu Générer, l'assembly portant le nom précédent est resté dans le bindossier et lorsque mon projet Web a été exécuté

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

l'exception ci-dessus a été levée, se plaignant que les méthodes d'interface dans les types Web d'implémentation n'étaient pas réellement implémentées. La suppression manuelle de l'assembly dans le bindossier du projet Web a résolu le problème.

J'ai également eu cette erreur lorsque j'avais précédemment activé la couverture de code lors des tests unitaires pour l'un des assemblys. Pour une raison quelconque, Visual Studio a "tamponné" l'ancienne version de cette DLL particulière même si je l'avais mise à jour pour implémenter une nouvelle version de l'interface. La désactivation de la couverture du code a permis de supprimer l'erreur.

Cette erreur peut également être provoquée si un assembly est chargé à l'aide de Assembly.LoadFrom (String) et fait référence à un assembly qui était déjà chargé à l'aide de Assembly.Load (Byte []).

Par exemple, vous avez incorporé les assemblys référencés de l'application principale en tant que ressources, mais votre application charge les plug-ins à partir d'un dossier spécifique.

Au lieu d'utiliser LoadFrom, vous devez utiliser Load. Le code suivant fera le travail:

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;
}

Une autre explication pour ce type de problème impliquant C ++ managé.

Si vous essayez de stub une interface définie dans un assembly créé à l'aide de C ++ managé qui a une signature spéciale, vous obtiendrez l'exception lorsque le stub est créé.

Cela est vrai pour Rhino Mocks et probablement tout framework de mocking qui utilise System.Reflection.Emit.

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

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

La définition d'interface obtient la signature suivante:

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

Notez que le type C ++ longcorrespond à System.Int32(ou simplement inten C #). C'est le quelque peu obscur modoptqui cause le problème comme l'a déclaré Ayende Rahien sur la liste de diffusion de Rhino Mocks .

Je viens de mettre à niveau une solution de MVC3 vers MVC5 et j'ai commencé à recevoir la même exception de mon projet de test unitaire.

J'ai vérifié toutes les références à la recherche d'anciens fichiers, j'ai finalement découvert que je devais faire des bindingRedirects pour Mvc, dans mon projet de test unitaire.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
        <bindingRedirect oldVersion="0.0.0.0-5.1.0.0" newVersion="5.1.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Dans mon cas, cela a aidé à réinitialiser la boîte à outils WinForms.

J'ai eu l'exception lors de l'ouverture d'un Formdans le concepteur; cependant, la compilation et l'exécution du code étaient possibles et le code s'est comporté comme prévu. L'exception s'est produite dans un local UserControlimplémentant une interface à partir d'une de mes bibliothèques référencées. L'erreur est apparue après la mise à jour de cette bibliothèque.

Cela a UserControlété répertorié dans la boîte à outils WinForms. Visual Studio a probablement conservé une référence sur une version obsolète de la bibliothèque ou mettait en cache une version obsolète quelque part.

Voici comment je me suis remis de cette situation:

1. Cliquez avec le bouton droit sur la boîte à outils WinForms et cliquez sur Reset Toolboxdans le menu contextuel. (Cela supprime les éléments personnalisés de la boîte à outils).
   Dans mon cas, les éléments Toolbox ont été restaurés à leur état par défaut; cependant, la flèche du pointeur manquait dans la boîte à outils.
2. Fermez Visual Studio.
   Dans mon cas, Visual Studio s'est terminé avec une exception de violation et a été abandonné.
3. Redémarrez Visual Studio.
   Maintenant, tout se passe bien.

FWIW, j'ai eu cela quand il y avait un fichier de configuration qui était redirigé vers une version inexistante d'un assembly référencé. Fusion des journaux pour la victoire!

J'ai eu cette erreur car j'avais une classe dans un assembly 'C' qui était sur la version 4.5 du framework, implémentant une interface dans l'assembly 'A' qui était sur la version 4.5.1 du framework et servant de classe de base à l'assembly 'B' qui était également sur la version 4.5.1 du framework. Le système a levé l'exception lors de la tentative de chargement de l'ensemble «B». De plus, j'avais installé des packages de nuget ciblant .net 4.5.1 sur les trois assemblys. Pour une raison quelconque, même si les références de pépite n'apparaissaient pas dans l'assemblage «B», la construction était réussie.

Il s'est avéré que le vrai problème était que les assemblys faisaient référence à différentes versions d'un package de nuget qui contenait l'interface et la signature de l'interface avait changé entre les versions.

Dans mon cas, j'avais déjà référencé un mylibprojet dans un dossier frère en dehors du dépôt - appelons cela v1.0.

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

Plus tard, je l'ai fait correctement et l'ai utilisé via un sous-module git - appelons cela v2.0. consoleAppCependant, un projet n'a pas été correctement mis à jour. Il faisait toujours référence à l'ancien v1.0projet en dehors de mon projet git.

Confusément , même si le *.csprojétait clairement faux et pointant vers v1.0, l'IDE de Visual Studio a montré le chemin d'accès en tant que v2.0projet! F12 pour inspecter l'interface et la classe est également passé à la v2.0version.

L'assembly placé dans le dossier bin par le compilateur était la v1.0version, d'où le mal de tête.

Le fait que l'IDE me mentait rendait encore plus difficile la réalisation de l'erreur.

Solution : Supprimez les références de projet ConsoleAppet ré-ajoutez-les.

Conseil général: recompilez tous les assemblages à partir de zéro (si possible, ne peut pas pour les packages de nuget bien sûr) et vérifiez les tampons datetime dans le bin\debugdossier. Tous les anciens assemblages datés sont votre problème.

J'ai rencontré presque le même problème. Je me grattais la tête ce qui cause cette erreur. J'ai recoupé, toutes les méthodes ont été mises en œuvre.

Sur Google, j'ai obtenu ce lien entre autres. D'après le commentaire de @Paul McLink, ces deux étapes ont résolu le problème.

1. Redémarrez Visual Studio
2. Nettoyer, construire (reconstruire)

et l' erreur a disparu .

Redémarrez le plugin VS

Merci Paul :)

J'espère que cela aide quelqu'un qui rencontre cette erreur :)

J'ai également rencontré ce problème lors de l'exécution de mes tests. L'application s'est bien déroulée et sans erreur. La cause du problème dans mon cas était que j'avais désactivé la construction des projets de test. La réactivation de la construction de mes projets de test a résolu les problèmes.

J'ai vu cela dans Visual Studio Pro 2008 lorsque deux projets ont créé des assemblys avec le même nom, un lib SDF.dll de classe et un qui a référencé la lib avec le nom d'assembly sdf.exe. Lorsque j'ai changé le nom de l'assemblage de référence, l'exception a disparu

Cela signifie simplement que le projet de mise en œuvre est obsolète dans mes cas. La DLL contenant l'interface a été reconstruite mais la DLL d'implémentation était périmée.

Voici mon point de vue sur cette erreur.

Ajout d'une externméthode, mais ma pâte était défectueuse. Ils se DllImportAttributesont mis sur une ligne commentée.

/// <returns>(removed for brevity lol)</returns>[DllImport("user32.dll")] 
[return: MarshalAs(UnmanagedType.Bool)]
public static extern bool IsWindowVisible(IntPtr hWnd);

S'assurer que l'attribut était réellement inclus dans la source a résolu le problème.

J'ai obtenu cela dans un service WCF en raison de la sélection d'un type de construction x86, ce qui obligeait les bacs à vivre sous bin \ x86 au lieu de bin. La sélection de N'importe quel CPU a provoqué le déplacement des DLL recompilées aux bons emplacements (je n'entrerai pas dans les détails quant à la façon dont cela s'est produit en premier lieu).

J'ai eu le même problème. J'ai compris que mon assemblage, qui est chargé par le programme principal, avait des références avec "Copy Local" défini sur true. Ces copies locales des références recherchaient d'autres références dans le même dossier, qui n'existaient pas car la «copie locale» des autres références était définie sur false. Après la suppression des références copiées "accidentellement", l'erreur a disparu car le programme principal a été configuré pour rechercher les emplacements corrects des références. Apparemment, les copies locales des références ont bousillé la séquence d'appel car ces copies locales ont été utilisées à la place des originaux présents dans le programme principal.

Le message à retenir est que cette erreur apparaît en raison du lien manquant pour charger l'assembly requis.

Dans mon cas, j'essayais d'utiliser TypeBuilderpour créer un type. TypeBuilder.CreateTypea jeté cette exception. J'ai finalement réalisé que je devais ajouter MethodAttributes.Virtualaux attributs lors de l'appel TypeBuilder.DefineMethodd'une méthode qui aide à implémenter une interface. En effet, sans cet indicateur, la méthode n'implémente pas l'interface, mais plutôt une nouvelle méthode avec la même signature à la place (même sans spécification MethodAttributes.NewSlot).

En complément: cela peut également se produire si vous mettez à jour un package de nuget qui a été utilisé pour générer un faux assemblage. Supposons que vous installiez la V1.0 d'un paquet de pépites et que vous créiez un faux assemblage "fakeLibrary.1.0.0.0.Fakes". Ensuite, vous mettez à jour vers la dernière version du package nuget, par exemple v1.1 qui a ajouté une nouvelle méthode à une interface. La bibliothèque Fakes recherche toujours la version 1.0 de la bibliothèque. Retirez simplement le faux assemblage et régénérez-le. Si tel était le problème, cela le corrigera probablement.

J'ai reçu cette erreur après une récente mise à jour de Windows. J'avais une classe de service définie pour hériter d'une interface. L'interface contenait une signature qui renvoyait un ValueTuple, une fonctionnalité assez nouvelle en C #.

Tout ce que je peux deviner, c'est que la mise à jour de Windows en a installé une nouvelle, mais qu'elle y a même fait explicitement référence, en mettant à jour les redirections de liaison, etc ...