System.MissingMethodException: Méthode non trouvée?
Ce qui fonctionnait jadis dans mon application asp.net webforms génère maintenant cette erreur:
System.MissingMethodException: méthode introuvable
La méthode DoThis est sur la même classe et devrait fonctionner.
J'ai un gestionnaire générique en tant que tel:
public class MyHandler: IHttpHandler
{
public void Processrequest(HttpContext context)
{
// throws error now System.MissingMethodException: Method not found?
this.DoThis();
}
public void DoThis()
{
//
}
}
C'est un problème qui peut survenir lorsqu'une ancienne version d'une DLL est toujours en attente. Assurez-vous que les derniers assemblys sont déployés et qu'aucun assemblage ancien dupliqué ne se cache dans certains dossiers. Votre meilleur choix serait de supprimer chaque élément construit et de reconstruire/redéployer la solution complète.
J'ai résolu ce problème en installant la version correcte de .NET Framework sur le serveur. Le site web tournait sous la version 4.0 et l’assemblée à laquelle il appelait était compilée 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.
Le redémarrage de Visual Studio a corrigé le problème pour moi. Je pense que cela a été causé par d'anciens fichiers Assembly encore utilisés. Effectuer une "construction propre" ou redémarrer VS devrait résoudre le problème.
Mauvaise version du paquet Nuget
J'avais un projet de test unitaire qui intégrait le paquet d'accès aux données de notre société EF Nuget et cette version était way derrière la version actuelle.
Les paramètres de nuget pour le paquet susmentionné ont été définis surleast versionpour ceux autres paquets qui étaient les paquets dépendants du deuxième niveau.
Par conséquent, a obtenu silencieusement la mauvaise version pour une Assemblée liée.
Solution
En définissant/mettant à jour le paquet dans Nuget vers [obtenir] le dernier corrige le problème.
Je viens de rencontrer cela sur un projet .NET MVC. La cause principale était des versions en conflit des paquets NuGet. J'ai eu une solution avec plusieurs projets. Chacun des projets comportait des packages NuGet. Dans un projet, j'avais une version du paquet Enterprise Library Semantic Logging, et dans deux autres projets (qui font référence au premier), j'avais d'anciennes versions du même paquet. Tout se compile sans erreur, mais cela a donné une erreur mystérieuse "Méthode non trouvée" lorsque j'ai essayé d'utiliser le paquet.
Le correctif consistait à supprimer les anciens packages NuGet des deux projets, afin de les inclure uniquement dans le projet qui en avait réellement besoin. (De plus, j’ai procédé à une reconstruction complète de la solution.)
Cela m'est arrivé avec un fichier référencé dans la même assemblée, pas une dll séparée. Une fois que j'ai exclu le fichier du projet, puis que je l'ai inclus à nouveau, tout a bien fonctionné.
Vérifiez vos références!
Assurez-vous de toujours indiquer les mêmes bibliothèques tierces (ne vous contentez pas de faire confiance aux versions, regardez 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 faites référence à iTextSharp v1.00.102 ailleurs, vous obtiendrez ces types d'erreur d'exécution qui se répercutent en quelque sorte dans votre code.
J'ai changé ma référence à iTextSharp dans les 3 projets pour pointer vers le même DLL et tout a fonctionné.
Si vous développez avec votre propre serveur NuGet, assurez-vous que les versions de Assembly sont toutes 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 de reconstruire à nouveau!
Je viens d'avoir ce problème et il s'est avéré que c'était parce que je faisais référence à une version précédente de la DLL de mon projet d'interface utilisateur. Par conséquent, lors de la compilation, c'était heureux. Mais lors de son 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.
Avez-vous essayé d'éteindre et d'allumer de nouveau? Blague à part, le redémarrage de mon ordinateur est ce qui a vraiment fait l'affaire pour moi 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é le VS, nettoyé et reconstruit le projet à nouveau. Après la prochaine publication, l'erreur avait disparu ...
Il est également possible que le problème concerne un paramètre ou le type de retour de la méthode signalée comme manquante, et la méthode "manquant" est satisfaisante.
C'est ce qui se passait dans mon cas, et le message trompeur a mis beaucoup de temps à comprendre 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 la version plus ancienne avait en fait un numéro de version plus élevé en raison d'une modification des schémas de numérotation de version utilisés. Supprimer cette version plus ancienne/supérieure du GAC a résolu le problème.
J'ai résolu ce problème en créant un plateau 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 libéré les modifications et recompilé le projet . Ainsi, vous nettoyerez toutes les "parties suspendues" présentes dans votre espace de travail et vous en lancerez une nouvelle . Cela nécessite bien sûr que vous utilisent TFS.
Dans mon cas, c’était un problème de copier/coller. J'ai en quelque sorte fini avec un constructeur PRIVATE pour mon profil de mappage:
using AutoMapper;
namespace Your.Namespace
{
public class MappingProfile : Profile
{
MappingProfile()
{
CreateMap<Animal, AnimalDto>();
}
}
}
(notez le "public" manquant devant le ctor)
qui compile parfaitement bien, mais quand AutoMapper tente d’instancier le profil, il ne peut pas (bien sûr!) trouver le constructeur!
Au cas où le problème serait dû à une ancienne version de l’Assembly dans le GAC .
Ceci peut aider: Comment: supprimer un assemblage du Global Assembly Cache .
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 faisait référence au projet DAL et à un autre projet nommé AnotherProj. Mon projet principal a fait un appel à Method1. Le projet AnotherProj faisait référence au projet DAL.CustSpec et non au projet DAL. La configuration de la construction avait les projets DAL et DAL.CustSpec configurés pour être générés. Une fois que tout a été créé, mon projet d’application Web contenait les assemblys AnotherProj et DAL dans son dossier Bin. Cependant, lorsque j'ai exécuté le site Web, le dossier Temporary ASP.NET pour celui-ci contenait l'assembly DAL.CustSpec dans ses fichiers et non l'assembly DAL, pour une raison quelconque. Bien entendu, 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 de DAL.CustSpec dans le projet AnotherProj à DAL uniquement, à 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 généré en le décochant dans la configuration de construction.
Je pensais partager cela au cas où cela aiderait quelqu'un d'autre à l'avenir.
En utilisant Costura.Fody 1.6 & 2.0:
Après avoir passé beaucoup de temps à chercher ce même type d'erreur avec toutes les autres solutions potentielles inefficaces, j'ai constaté qu'une ancienne version de la DLL que j'étais en train d'incorporer se trouvait dans le même répertoire compilé .exe à partir de. Apparemment, il cherche d'abord un fichier local dans le même répertoire, puis cherche à l'intérieur sa bibliothèque intégrée. La suppression de l’ancien DLL a fonctionné.
Pour être clair, ce n'était pas que ma référence pointait vers une ancienne DLL, mais bien qu'une copie d'un ancien DLL se trouvait dans le répertoire dans lequel je testais mon application sur un système distinct de celui où elle se trouvait. compilé sur.
Juste au cas où cela aiderait quelqu'un, bien que ce soit un problème ancien, mon problème était un peu étrange.
J'ai eu cette erreur en utilisant Jenkins.
Finalement, nous avons découvert que la date du système avait été définie manuellement sur une date ultérieure, ce qui a entraîné la compilation de la DLL avec cette date. Lorsque la date a été ramenée à la normale, MSBuild a interprété que le fichier était plus récent et ne nécessitait pas de recompilation du projet.
J'ai rencontré ce problème. Un projet utilisait une liste qui était dans l'espace de noms Example.Sensors et un autre type implémentait l'interface ISensorInfo. Classe Type1SensorInfo, mais cette classe était une couche plus profonde dans l’espace de noms de Example.Sensors.Type1. Lors de la tentative de désérialisation de Type1SensorInfo dans la liste, l’exception a été renvoyée. Lorsque j'ai ajouté à l'aide de Example.Sensors.Type1 dans l'interface ISensorInfo, plus d'exception!
namespace Example
{
public class ConfigFile
{
public ConfigFile()
{
Sensors = new List<ISensorInfo<Int32>>();
}
public List<ISensorInfo<Int32>> Sensors { get; set; }
}
}
}
**using Example.Sensors.Type1; // Added this to not throw the exception**
using System;
namespace Example.Sensors
{
public interface ISensorInfo<T>
{
String SensorName { get; }
}
}
using Example.Sensors;
namespace Example.Sensors.Type1
{
public class Type1SensorInfo<T> : ISensorInfo<T>
{
public Type1SensorInfo()
}
}
Dans mon cas, c’était un dossier avec des DLL plus anciennes du même nom que celles qui étaient référencées dans mon fichier .csproj bien que le chemin soit explicitement indiqué, elles étaient en quelque sorte incluses;
J'ai eu ce problème lorsque la méthode nécessitait un paramètre que je ne spécifiais pas
Dans mon cas, mon projet faisait référence à Microsoft.Net.Compilers.2.10.0. Lorsque je suis passé à Microsoft.Net.Compilers.2.7.0, l'erreur a disparu. Quelle erreur mystérieuse avec une telle variété de causes.
Doit être un bug de référence de Microsoft.
J'ai nettoyé, reconstruit sur toutes mes bibliothèques et j'ai toujours le même problème et je ne pouvais pas le résoudre.
Je n'ai fait que fermer l'application Visual Studio et l'ouvrir à nouveau. Cela a fait le tour.
Il est très frustrant qu’un problème aussi simple puisse prendre si longtemps à résoudre car vous ne penseriez pas que ce sera quelque chose comme ça.
Dans mon cas, il n'y a pas eu de changement de code du tout et tout à coup, l'un des serveurs a commencé à obtenir cette exception et uniquement cette exception (tous les serveurs ont le même code, mais un seul a eu des problèmes):
System.MissingMethodException: Method not found: '?'.
Empiler:
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(String ID, String HashID, searchtPhone Phone1)
at WS.MyValidation(String AccountNumber, String PhoneNumber)
Je pense que le problème était corrompu AppPool - nous avons automatisé le recyclage d'AppPool tous les jours à 3 heures du matin. Le problème a commencé à 3 heures du matin et a pris fin à 3 heures le lendemain.
Dans mon cas, spotify.exe utilisait le même port que mon projet d’API Web souhaitait utiliser sur une machine de développement. Le numéro de port était 4381.
J'ai quitté Spotify et tout a bien fonctionné encore :)
J'ai eu la même chose quand un certain nombre de processus MSBuild exécutés en arrière-plan s'étaient effectivement bloqués (ils avaient des références à d'anciennes versions de code). J'ai fermé VS et ai tué tous les processus MSBuild dans le processus Explorer, puis recompilé.
J'ai eu un projet de test qui référence 2 autres projets qui chacun ont référencé différentes versions (dans différents emplacements) de la même DLL. Cela a dérouté le compilateur.
Cela m'est arrivé en utilisant MVC4 et j'ai décidé, après avoir lu ce fil, de renommer l'objet à l'origine de l'erreur.
J'ai fait un nettoyage et une reconstruction et j'ai remarqué que deux projets étaient ignorés. Lorsque j'ai reconstruit l'un d'eux, il y avait une erreur où j'avais démarré une fonction et non pas fini.
Donc, VS faisait référence à un modèle que j'avais réécrit sans me demander si je voulais le faire.