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

270

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.

Benjol
la source
15
J'adore la façon dont vous avez partagé votre expérience avec la communauté pour nous aider tous, et même nous a encouragés à lire les autres réponses aussi, merci. Malheureusement, aucune des suggestions n'a fonctionné pour moi. Vous voulez savoir ce qui a fini par fonctionner pour moi? Redémarrage de Visual Studio. Pourquoi n'ai-je pas essayé cela en premier?
Paul McLean
Merci Paul, après avoir lu votre commentaire, j'ai essayé celui-là en premier. A fonctionné comme un charme :-)
Jan_V
merci Paul, sauve-moi quelques heures en me grattant continuellement la tête comme un singe ...
Kien Chu
De plus, après la mise à jour de VS 2017 15.7, VS vous demande de redémarrer. Vous ne l'avez peut-être pas fait (comme moi, à cause des réunions que j'ai oubliées). J'ai eu des téléchargements d'erros comme ceux-ci ...
Structuré
Juste pour ajouter mon 2p - j'ai eu ce problème lors de l'exécution de tests unitaires dans MsTest. Les classes testées étaient dans un assemblage signé. Une version différente de cette assemblée se trouvait au GAC. MsTest récupérait l'assembly GAC plutôt que d'utiliser celui du dossier bin et essayait d'exécuter les tests par rapport à celui-ci, ce qui ne fonctionnait évidemment pas. La solution était de retirer l'assemblage du GAC
Tom Redfern

Réponses:

244

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.

Benjol
la source
1
Vous devrez peut-être ajouter que l'application Console doit être reconstruite avec les nouvelles DLL comme référence. Le simple fait de copier la DLL ne fonctionnera pas et cela pourrait être dû à une incompatibilité de version (c'est-à-dire qu'après avoir compilé la DLL source, la version changera). Est-ce une bonne compréhension?
shahkalpesh
@shahkalpesh bon point - pour moi, «courir à nouveau» impliquait F5. J'ai mis à jour la réponse. Bien sûr, tout cela ne serait pas arrivé avec un outil de contrôle de source décent, mais ne me
lancez
4
Hmm, on dirait que le message d'erreur de Microsoft contient une erreur - il dit qu'une méthode de classe "DummyItem" n'a pas d'implémentation, ce qui est manifestement faux .... vraiment le problème est qu'une méthode de l'interface n'est pas pas implémenté par DummyItem.
Qwertie
3
une bonne solution finale à ce sujet? Quelle solution Microsoft a-t-elle recommandée?
Kiquenet
12
La solution consiste à supprimer les fichiers bin manuellement. La publication ne les voit pas comme modifiées, vous devez donc la forcer à avoir la dernière version. Cela devrait vraiment être noté dans la réponse la mieux notée!
DJ.
33

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
Timwi
la source
Cela a résolu le problème pour moi, avec le niveau supplémentaire d'obscurcissement que la méthode qui, selon elle, manquait, a été déclaré dans une interface implémentée par une classe parent, et déclaré à nouveau dans la sous-classe. La suppression du doublon de la sous-classe a fait disparaître l'erreur.
ilikeprogramming
22

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

ton silencieux
la source
19

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?
Ben
la source
17

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!

Damien Sawyer
la source
J'avais quelque chose de similaire mais l'inverse avec les versions. Une méthode, ciblant .NET 2, a renvoyé un type de la version 2 de System.Windows.Forms. Son implémentation remplacée dans un assembly .NET 4 ciblé a renvoyé le même type mais à partir de la version 4 de System.Windows.Forms. Il s'est bien compilé mais ReflectionOnlyLoadFrom ne l'a pas aimé.
Stephen Hewlett
J'ai eu un problème similaire causé par le chargement de types qui ciblaient .NET2 dans un contexte ReflectionOnly d'une application .NET4. J'ai contourné le problème en redirigeant toutes les demandes d'assembly des assemblys de base .NET2 vers leurs homologues .NET4 dans l'événement AppDomain.ReflectionOnlyAssemblyResolve.
Chaquotay
C'était mon problème :) Merci!
Antoan Elenkov
13

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.

Tim
la source
9

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.

Richard Dingwall
la source
6

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.

DJ.
la source
J'ai trouvé que c'était également le cas dans un projet non Web - je réfléchissais un assemblage dans un autre (à l'aide de LoadFile), le nettoyage et la reconstruction ne fonctionnaient pas - la suppression de tous les fichiers du dossier bin des deux projets fonctionnait. Bravo pour la suggestion!
d219
J'ai également dû effectuer une réinitialisation IIS car ce projet particulier utilise IIS localement (malheureusement).
Tim Wilson
6

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.

Tony Pulokas
la source
Ce fut la réponse pour moi. J'ai rencontré cette erreur après la mise à niveau de .NET 4.5 vers 4.6.
twblamer
6

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>
Hydrargyrum
la source
Puis-je vous demander comment vous l'avez trouvé? Avez-vous utilisé une technique de débogage non standard? J'obtiens la même erreur mais je pense que cela est causé par une DLL différente car j'ai déjà une redirection de liaison pour les immuables.
t3chb0t
1
Hmm. C'était il y a quelque temps. Je pense que le principal indice était que les paramètres de la méthode "non implémentée" utilisaient des types de System.Collections.Immutable. Dans mon cas, il n'y avait pas beaucoup d'autres paramètres candidats ou types de retour dans la méthode affectée. Je me souviens également d'avoir utilisé ILSpy pour inspecter les métadonnées de dépendance dans les DLL "DefinitionAssembly" et "ImplementationAssembly" compilées, en examinant spécifiquement les versions des références.
Hydrargyrum
1
Merci beaucoup! ;-) J'ai installé l'extension ILSpy pour Visual Studio et regardé la branche Références, il y en avait une pour le System.Net.Httppackage, j'ai ajouté l' dependentAssemblyélément pour elle et copié les informations depuis ILSpy et ça marche maintenant, l'erreur a disparu!
t3chb0t
J'ai compris quel était le mauvais assemblage GAC en le mettant dans le code et en plaçant un point d'arrêt juste après pour regarder les valeurs et en voyant deux versions de System.Net.Http ont été chargées: var LoadAssemblies = à partir d'un dans AppDomain.CurrentDomain. GetAssemblies () orderby a.FullName select (a.FullName, a);
paulie4
5

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

Serge Desmedt
la source
16
Oui, j'aime à penser que c'est le problème de Renault
Benjol
Je pense que j'avais une version similaire de ce problème, mais juste entre deux projets. J'ai compilé le nouveau manuellement. Après cela, cela a fonctionné en douceur.
Departamento B
5

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.

G-Wiz
la source
4

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.

Kyberias
la source
4

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;
}
FrankCoder
la source
3

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 .

Martin Liversage
la source
J'ai eu cette erreur lorsque j'ai utilisé le type de données System::Byte. J'ai changé la signature pour accepter un unsigned shortet le ciel était de nouveau bleu.
Krishter
3

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>
shenku
la source
3

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.
Olivier Jacot-Descombes
la source
3

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!

Tilman
la source
3

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.

Tolu
la source
3

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.

décret
la source
3

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 :)

Kgn-web
la source
2

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.

Wesley
la source
2

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

N romaai
la source
2

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.

TrustyCoder
la source
2

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.


la source
2

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

Ruben Bartelink
la source
1

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.

Almis
la source
1

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

James
la source
1

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.

Chris Peterson
la source
1

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

Mike_G
la source