System.MissingMethodException: Méthode introuvable?

C’est un problème qui peut survenir lorsqu’une ancienne version d’une DLL est toujours présente. Assurez-vous que les derniers assemblys sont déployés et qu’aucun ancien assemblage dupliqué ne se cache dans certains dossiers. Votre meilleur pari serait de supprimer tous les éléments construits et de reconstruire / redéployer la solution entière.

J’ai résolu ce problème en installant la version correcte de .NET Framework sur le serveur. Le site Web fonctionnait sous la version 4.0 et l’assembly auquel il appelait a été compilé pour la version 4.5. Après l’installation de .NET Framework 4.5 et la mise à niveau du site Web vers la version 4.5, tout fonctionne correctement.

Redémarrer Visual Studio l’a effectivement corrigé. Je pense que cela a été causé par d’anciens fichiers d’assemblage encore en cours d’utilisation, et effectuer une “Build Build” ou redémarrer le VS devrait le réparer.

Mauvaise version du package Nuget

J’avais un projet de test unitaire qui intégrait le paquet d’access aux données EF Nuget de notre entreprise et cette version était loin derrière la version actuelle.

Les parameters de Nuget pour le paquet susmentionné utilisaient la least version la least version basse pour les autres paquetages qui étaient les paquets dépendant du deuxième niveau.

Par conséquent, il a silencieusement obtenu la mauvaise version pour un assemblage connexe .

Solution

En configurant / mettant à jour le paquet dans Nuget pour [obtenir] le dernier problème résolu.

Je viens de courir sur un projet .NET MVC. La cause principale était des versions contradictoires des packages NuGet. J’ai eu une solution avec plusieurs projets. Chacun des projets comportait des packages NuGet. Dans un projet, j’avais une version du package Enterprise Library Semantic Logging et, dans deux autres projets (qui font référence au premier), j’avais des versions plus anciennes du même package. Tout se comstack sans erreur, mais cela a donné une mystérieuse erreur “Méthode introuvable” lorsque j’ai essayé d’utiliser le paquet.

La solution consistait à supprimer les anciens packages NuGet des deux projets, afin qu’ils ne soient inclus que dans le projet qui en avait réellement besoin. (Aussi j’ai fait une reconstruction propre de toute la solution.)

Cela m’est arrivé avec un fichier référencé dans le même assemblage, pas une DLL distincte. Une fois que j’ai exclu le fichier du projet et que je l’ai à nouveau inclus, tout s’est bien passé.

Si vous développez avec votre propre serveur NuGet, assurez-vous que les versions d’assemblage sont identiques:

 [assembly: AssemblyVersion("0.2.6")] [assembly: AssemblyFileVersion("0.2.6")] [assembly: AssemblyInformationalVersion("0.2.6")] 

aussi .. essayez de “nettoyer” vos projets ou solutions et reconstruire à nouveau!

Je viens d’avoir ce problème et il s’est avéré que c’était parce que je référençais une version précédente de la DLL de mon projet d’interface utilisateur. Par conséquent, lors de la compilation était heureux. Mais lors de l’exécution, il utilisait la version précédente de la DLL.

Vérifiez les références sur tous les autres projets avant de supposer que vous devez reconstruire / nettoyer / redéployer vos solutions.

Vérifiez vos références!

Assurez-vous que vous pointez systématiquement vers les mêmes bibliothèques tierces (ne faites pas uniquement confiance aux versions, examinez le chemin) dans vos projets de solutions.

Par exemple, si vous utilisez iTextSharp v.1.00.101 dans un projet et que vous utilisez NuGet ou que vous référencez iTextSharp v1.00.102 ailleurs, vous obtiendrez ces types d’erreurs d’exécution qui se répercuteront dans votre code.

J’ai changé ma référence à iTextSharp dans les 3 projets pour pointer vers la même DLL et tout fonctionnait.

J’ai eu un scénario similaire où je recevais cette même exception. J’avais deux projets dans ma solution d’application Web, nommés par exemple DAL et DAL.CustSpec. Le projet DAL avait une méthode nommée Method1, mais pas DAL.CustSpec. Mon projet principal comportait une référence au projet DAL et une référence à un autre projet nommé AnotherProj. Mon projet principal a appelé Method1. Le projet AnotherProj faisait référence au projet DAL.CustSpec et non au projet DAL. La configuration de la construction comportait la configuration des projets DAL et DAL.CustSpec. Une fois que tout a été construit, mon projet d’application Web contenait les assemblages AnotherProj et DAL dans son dossier Bin. Toutefois, lorsque j’ai exécuté le site Web, le dossier ASP.NET temporaire du site Web contenait l’assembly DAL.CustSpec dans ses fichiers et non l’assembly DAL, pour une raison quelconque. Bien sûr, lorsque j’ai exécuté la partie qui appelait Method1, j’ai reçu une erreur “Méthode introuvable”.

Ce que je devais faire pour corriger cette erreur consistait à modifier la référence dans le projet AnotherProj de DAL.CustSpec pour qu’elle ne soit plus que DAL, à supprimer tous les fichiers du dossier Temporary ASP.NET Files, puis à réexécuter le site Web. Après cela, tout a commencé à fonctionner. Je me suis également assuré que le projet DAL.CustSpec n’était pas en cours de construction en le décochant dans la configuration de la construction.

J’ai pensé partager cela au cas où cela aiderait quelqu’un d’autre à l’avenir.

Avez-vous essayé de désactiver et de rallumer? Blague à part, redémarrer mon ordinateur a été ce qui a vraiment fait l’affaire et n’est mentionné dans aucune des autres réponses.

Je suis tombé sur la même situation sur mon site Web ASP.NET. J’ai supprimé les fichiers publiés, redémarré VS, nettoyé et reconstruit le projet à nouveau. Après la publication suivante, l’erreur avait disparu …

J’ai résolu ce problème en créant une étagère avec mes modifications et en exécutant «scorch» de TFS Power Tools dans mon espace de travail ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Ensuite, j’ai dégagé les modifications et recompilé le projet. De cette façon, vous nettoyerez les «parties suspendues» présentes dans votre espace de travail et vous les lancerez avec une nouvelle. Cela nécessite, bien sûr, que vous utilisiez TFS.

Dans mon cas, c’était un problème de copier / coller. Je me suis retrouvé avec un constructeur PRIVATE pour mon profil de mappage:

 using AutoMapper; namespace Your.Namespace { public class MappingProfile : Profile { MappingProfile() { CreateMap(); } } } 

(prendre note du “public” manquant devant le ctor)

ce qui comstack parfaitement bien, mais quand AutoMapper essaie d’instancier le profil, il ne peut pas (bien sûr!) trouver le constructeur!

Utilisation de Costura.Fody 1.6 et 2.0:
Après avoir perdu beaucoup de temps à examiner le même type d’erreur avec toutes les autres solutions potentielles qui ne fonctionnaient pas, j’ai constaté qu’une ancienne version de la DLL que je intégrais se trouvait dans le même répertoire que celui dans lequel j’exécutais mon fichier .exe nouvellement compilé. Apparemment, il recherche d’abord un fichier local dans le même répertoire, puis regarde sa bibliothèque intégrée. La suppression de l’ancienne DLL a fonctionné.

Pour être clair, ce n’est pas que ma référence pointait vers une ancienne DLL, c’était qu’une copie d’une ancienne DLL se trouvait dans le répertoire où je testais mon application sur un système distinct de celui sur lequel elle avait été compilée.

Cela m’est arrivé en utilisant MVC4, et j’ai décidé, après avoir lu ce fil de discussion, de renommer l’object à l’origine de l’erreur.

J’ai fait un nettoyage et une reconstruction et j’ai noté que deux projets étaient en cours. Lorsque j’en reconstruisais une, il y avait une erreur où j’avais démarré une fonction et ne l’avais pas terminée.

Donc, VS faisait référence à un modèle que j’avais réécrit sans me demander si je voulais le faire.

Juste au cas où cela aiderait quelqu’un, même si c’est un vieux problème, mon problème était un peu étrange.

J’ai eu cette erreur en utilisant Jenkins.

Éventuellement, a découvert que la date du système était définie manuellement sur une date ultérieure, ce qui entraînait la compilation de dll avec cette date future. Lorsque la date a été remise à la normale, MSBuild a interprété que le fichier était plus récent et ne nécessitait pas de recompilation du projet.

Je me suis heurté à ce problème, et ce que cela représentait pour moi était d’utiliser un List qui se trouvait dans l’espace de noms Example.Sensors et un autre type implémentait l’interface ISensorInfo. Classe Type1SensorInfo, mais cette classe était plus profonde dans l’espace de noms dans Example.Sensors.Type1. Lors de la tentative de désérialisation de Type1SensorInfo dans la liste, il a déclenché l’exception. Lorsque j’ai ajouté à l’aide de Example.Sensors.Type1 dans l’interface ISensorInfo, plus aucune exception!

 namespace Example { public class ConfigFile { public ConfigFile() { Sensors = new List>(); } public List> Sensors { get; set; } } } } **using Example.Sensors.Type1; // Added this to not throw the exception** using System; namespace Example.Sensors { public interface ISensorInfo { Ssortingng SensorName { get; } } } using Example.Sensors; namespace Example.Sensors.Type1 { public class Type1SensorInfo : ISensorInfo { public Type1SensorInfo() } } 

J’ai eu la même chose quand j’ai eu un certain nombre de processus MSBuild en cours d’exécution en arrière-plan qui avaient effectivement échoué (ils avaient des références aux anciennes versions de code). J’ai fermé VS et tué tous les processus MSBuild dans l’explorateur de processus, puis recompilé.

J’ai eu un projet de test qui référence 2 autres projets qui référencent chacun des versions différentes (à des endroits différents) de la même DLL. Cela a confondu le compilateur.

Dans mon cas, spotify.exe utilisait le même port que mon projet web api voulait utiliser sur une machine de développement. Le numéro de port était 4381.

J’ai quitté Spotify et tout a bien fonctionné 🙂

Il est également possible que le problème soit lié à un paramètre ou à un type de retour de la méthode signalée manquante, et la méthode “manquante” en elle-même convient.

C’est ce qui se passait dans mon cas et le message trompeur a mis beaucoup plus de temps à résoudre le problème. Il s’avère que l’assemblage d’un type de paramètre avait une version plus ancienne dans le GAC, mais que l’ancienne version contenait en réalité un numéro de version plus élevé en raison d’une modification des schémas de numérotation des versions utilisés. La suppression de cette version antérieure / supérieure du GAC a résolu le problème.

J’ai eu ce problème lorsque la méthode nécessitait un paramètre que je ne spécifiais pas

Dans mon cas, il n’y a pas eu de changement de code du tout et soudain l’un des serveurs a commencé à recevoir ceci et seulement cette exception (tous les serveurs ont le même code, mais un seul a commencé à avoir des problèmes):

 System.MissingMethodException: Method not found: '?'. 

Emstackr:

 Server stack trace: at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message) Exception rethrown at [0]: at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request) at myAccountSearch.AccountSearchClient.myAccountSearch.AccountSearch.searchtPhone(searchtPhoneRequest request) at myAccountSearch.AccountSearchClient.searchtPhone(Ssortingng ID, Ssortingng HashID, searchtPhone Phone1) at WS.MyValidation(Ssortingng AccountNumber, Ssortingng PhoneNumber) 

Le problème, je crois, était que AppPool était corrompu – nous avons automatisé le recyclage AppPool qui a lieu tous les jours à 3 heures du matin et le problème a commencé à 3 heures du matin, puis s’est terminé seul à 3 heures le lendemain.