System.MissingMethodException: méthode introuvable?

Ce qui fonctionnait autrefois dans mon application webforms asp.net génère maintenant cette erreur:

System.MissingMethodException: méthode introuvable

La DoThisméthode 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()
    {
    //
    }
}

Il s'agit d'un problème qui peut se produire lorsqu'une ancienne version d'une DLL persiste toujours quelque part. Assurez-vous que les derniers assemblys sont déployés et qu'aucun assemblage plus ancien ne se cache dans certains dossiers. Votre meilleur pari serait de supprimer chaque élément construit et de reconstruire / redéployer la solution entière.

⚠️ Version incorrecte du package Nuget ⚠️

J'avais un projet de test unitaire qui intégrait le package d'accès aux données EF Nuget de notre entreprise et ce code extrait dans un package externe dont la version était bien en retard sur la version actuelle.

Le problème était que les paramètres Nuget du package étaient définis sur least version; et l'ancienne version a gagné et a été utilisée pendant les opérations ....

Par conséquent, il a obtenu silencieusement la mauvaise version pour un assemblage commun utilisé à la fois par le package et l'application.

💡 Solution 💡

En définissant / mettant à jour le package dans Nuget pour utiliser et [obtenir] la dernière version , le problème a été résolu.

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 était compilé pour 4.5. Après l'installation de .NET Framework 4.5 et la mise à niveau du site Web vers 4.5, tout fonctionne bien.

Le redémarrage de Visual Studio l'a en fait corrigé pour moi. Je pense que cela a été causé par d'anciens fichiers d'assemblage encore en cours d'utilisation, et effectuer une "Clean Build" ou redémarrer VS devrait le corriger.

J'ai eu cela m'arriver 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, puis l'ai à nouveau inclus, tout a bien fonctionné.

Je viens de rencontrer cela sur un projet .NET MVC. La cause principale était les versions conflictuelles des packages NuGet. J'avais une solution avec plusieurs projets. Chacun des projets avait 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 compile sans erreur, mais il a donné une mystérieuse erreur "Méthode non trouvée" lorsque j'ai essayé d'utiliser le package.

Le correctif 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. (J'ai également fait une reconstruction propre de toute la solution.)

Vérifiez vos références!

Assurez-vous que vous pointez constamment vers 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 NuGet ou référencez iTextSharp v1.00.102 ailleurs, vous obtiendrez ces types d'erreurs 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 la même DLL et tout a fonctionné.

Si vous développez avec votre propre serveur NuGet, assurez-vous que les versions d'assembly sont toutes les mêmes:

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

aussi .. essayez de "nettoyer" vos projets ou solution et reconstruisez à nouveau!

Avez-vous essayé de l'éteindre et de le rallumer? Blagues à part, le redémarrage de mon ordinateur a été ce qui m'a vraiment fait l'affaire et n'est mentionné dans aucune des autres réponses.

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, il é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.

Dans mon cas, c'était un problème de copier / coller. Je me suis retrouvé en quelque sorte avec un constructeur PRIVÉ pour mon profil de mappage:

using AutoMapper;

namespace Your.Namespace
{
    public class MappingProfile : Profile
    {
        MappingProfile()
        {
            CreateMap<Animal, AnimalDto>();
        }
    }
}

(prendre note du "public" manquant devant le ctor)

qui a compilé parfaitement bien, mais lorsque AutoMapper essaie d'instancier le profil, il ne peut pas (bien sûr!) trouver le constructeur!

J'ai eu un scénario similaire où je recevais cette même exception levée. J'ai eu 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 avait une référence au projet DAL et également une référence à un autre projet nommé AnotherProj. Mon projet principal a appelé la méthode 1. Le projet AnotherProj faisait référence au projet DAL.CustSpec et non au projet DAL. La configuration de construction avait les projets DAL et DAL.CustSpec configurés pour être construits. Une fois que tout a été construit, mon projet d'application Web avait les assemblages AnotherProj et DAL dans son dossier Bin. Cependant, lorsque j'ai exécuté le site Web, le dossier ASP.NET temporaire du site Web avait l'assembly DAL.CustSpec dans ses fichiers et non l'assembly DAL, pour certaines raisons. Bien sûr, lorsque j'ai exécuté la partie qui a appelé Method1, j'ai reçu une erreur "Méthode non trouvée".

Ce que je devais faire pour corriger cette erreur était de changer la référence dans le projet AnotherProj de DAL.CustSpec à seulement DAL, de supprimer tous les fichiers du dossier Fichiers temporaires ASP.NET, puis de réexécuter le site Web. Après cela, tout a commencé à fonctionner. J'ai également vérifié 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é que je partagerais cela au cas où cela aiderait quelqu'un d'autre à l'avenir.

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

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

Il est également possible que le problème soit avec un paramètre ou un type de retour de la méthode signalée manquante, et la méthode "manquante" en soi est très bien.

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

Utilisation de Costura.Fody 1.6 & 2.0:
Après avoir perdu beaucoup de temps à rechercher ce même type d'erreur avec toutes les autres solutions potentielles ne fonctionnant pas, j'ai constaté qu'une ancienne version de la DLL que j'incorporais se trouvait dans le même répertoire que celui où j'exécutais mon .exe nouvellement compilé à partir de. Apparemment, il cherche d'abord un fichier local dans le même répertoire, puis regarde vers l'intérieur dans sa bibliothèque intégrée. La suppression de l'ancienne DLL a fonctionné.

Pour être clair, ce n'était 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 dans lequel je testais mon application sur un système distinct de celui sur lequel elle était compilée.

Dans mon cas, il s'agissait d'un dossier contenant des DLL plus anciennes du même nom que celles qui étaient référencées dans mon fichier .csproj bien que le chemin d'accès ait été explicitement indiqué, elles étaient en quelque sorte incluses, donc les différentes versions des mêmes DLL étaient en conflit.

Dans le cas où le problème est causé par une ancienne version de l'assembly dans le GAC .
Cela peut aider: Comment: supprimer un assembly du Global Assembly Cache .

Dans mon cas, la MissingMethodException était pour une méthode qui était dans le même fichier!

Cependant, je venais d'ajouter un package NuGet qui utilise .Net Standard2 à mon projet de ciblage 4.7.1, ce qui a provoqué un conflit de version pour System.Net.Http (4.7.1: version 4.0.0.0, le package NuGet utilisant .NET La norme 2 veut 4.2.0.0). Cela semble être des problèmes connus qui devraient être améliorés dans 4.7.2 (voir note 2) .

J'avais utilisé une redirection de liaison comme celle-ci dans tous mes autres projets, car il y avait des exceptions dès qu'il essayait de charger le 4.2.0.0 que je n'avais pas:

  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
  </dependentAssembly>

Sauf dans ce seul projet, où il semble qu'il essaie de charger System.Net.Http uniquement lors de l' appel d'une fonction locale qui utilise un System.Net.Http.HttpResponseMessage comme paramètre ou type de retour (paramètre pendant le débogage, type de retour lorsque j'exécute) les tests sans le débogueur, aussi un peu étranges). Et au lieu d'afficher un message indiquant qu'il n'a pas pu charger la version 4.2.0.0 de System.Net.Http, il renvoie cette exception.

Cela m'est arrivé en utilisant MVC4, et j'ai décidé après avoir lu ce fil de renommer l'objet qui lançait l'erreur.

J'ai fait un nettoyage et une reconstruction et j'ai noté qu'il sautait deux projets. Quand j'ai reconstruit l'un d'eux, il y avait une erreur où j'avais démarré une fonction et je ne l'avais pas terminée.

VS faisait donc 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 lors de l'utilisation de Jenkins.

Finalement découvert que la date système a été manuellement réglée sur une date future, ce qui a provoqué la compilation de dll avec cette date future. Lorsque la date est revenue à 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, et ce que c'était pour moi était qu'un projet utilisait une liste qui était dans l'espace de noms Example.Sensors et qu'un autre type implémentait l'interface ISensorInfo. Classe Type1SensorInfo, mais cette classe était plus profonde d'une couche dans l'espace de noms à Example.Sensors.Type1. Lors de la tentative de désérialisation de Type1SensorInfo dans la liste, il a levé l'exception. Lorsque j'ai ajouté en utilisant 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() 
    }
}

J'ai eu la même chose se produire lorsque j'avais un certain nombre de processus MSBuild en cours d'exécution qui avaient effectivement planté (ils avaient des références à d'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 fait référence à 2 autres projets qui référencent chacun des versions différentes (dans 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 d'API Web voulait utiliser sur une machine de développement. Le numéro de port était 4381.

J'ai quitté Spotify et tout a bien fonctionné à nouveau :)

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 eu aucun changement de code et soudain, l'un des serveurs a commencé à obtenir 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: '?'.

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)

Le problème, je crois, était corrompu AppPool - nous avons automatisé le recyclage AppPool en cours tous les jours à 3 heures du matin et le problème a commencé à 3 heures du matin puis s'est terminé de lui-même à 3 heures du matin le lendemain.

Doit être un bogue de référence de Microsoft.

J'ai nettoyé, reconstruit toutes mes bibliothèques et j'ai toujours eu le même problème et je n'ai pas pu résoudre ce problème.

Je n'ai fait que fermer l'application Visual Studio et l'ouvrir à nouveau. Cela a fait l'affaire.

C'est très frustrant qu'un problème aussi simple puisse prendre autant de temps à résoudre car vous ne penseriez pas que ce sera quelque chose comme ça.

Dans mon cas, mon projet faisait référence Microsoft.Net.Compilers.2.10.0. Lorsque je l'ai changé Microsoft.Net.Compilers.2.7.0, l'erreur a disparu. Quelle mystérieuse erreur avec une telle variété de causes.