System.MissingMethodException: Methode nicht gefunden?

Was früher in meiner asp.net-Webforms-App funktionierte, löst jetzt diesen Fehler aus:

System.MissingMethodException: Methode nicht gefunden

Die DoThisMethode befindet sich in derselben Klasse und sollte funktionieren.

Ich habe einen generischen Handler als solchen:

public class MyHandler: IHttpHandler
{
    public void Processrequest(HttpContext context)
    {
      // throws error now System.MissingMethodException: Method not found?
      this.DoThis(); 
    }

    public void DoThis()
    {
    //
    }
}

Dies ist ein Problem, das auftreten kann, wenn noch eine alte Version einer DLL vorhanden ist. Stellen Sie sicher, dass die neuesten Assemblys bereitgestellt werden und keine doppelten älteren Assemblys in bestimmten Ordnern versteckt sind. Am besten löschen Sie alle erstellten Elemente und erstellen die gesamte Lösung neu.

⚠️ Falsche Nuget-Paketversion ⚠️

Ich hatte ein Unit-Test-Projekt, bei dem das interne EF Nuget-Datenzugriffspaket unseres Unternehmens abgerufen wurde, und dieser Code wurde in einem externen Paket abgerufen , dessen Version weit hinter der aktuellen Version zurückblieb.

Das Problem war, dass die Nuget-Einstellungen für das Paket auf least version; und die ältere Version gewann und wurde während des Betriebs verwendet ....

Daher hat es stillschweigend die falsche Version für eine gemeinsame Assembly erhalten, die sowohl vom Paket als auch von der App verwendet wird.

💡 Lösung 💡

Das Problem wurde behoben, indem das Paket in Nuget so eingestellt / aktualisiert wurde, dass es verwendet und das neueste [ abgerufen ] wird .

Ich habe dieses Problem behoben, indem ich die richtige .NET Framework-Version auf dem Server installiert habe. Die Website wurde unter Version 4.0 ausgeführt und die aufgerufene Assembly wurde für 4.5 kompiliert. Nach der Installation von .NET Framework 4.5 und dem Upgrade der Website auf 4.5 funktioniert alles einwandfrei.

Durch einen Neustart von Visual Studio wurde das Problem für mich behoben. Ich denke, es wurde durch alte Assembly-Dateien verursacht, die noch verwendet werden, und ein "Clean Build" oder ein Neustart von VS sollte das Problem beheben.

Mir ist dies mit einer Datei passiert, auf die in derselben Assembly verwiesen wird, nicht mit einer separaten DLL. Nachdem ich die Datei aus dem Projekt ausgeschlossen und dann wieder aufgenommen hatte, funktionierte alles einwandfrei.

Ich bin gerade in einem .NET MVC-Projekt darauf gestoßen. Die Hauptursache waren widersprüchliche Versionen von NuGet-Paketen. Ich hatte eine Lösung mit mehreren Projekten. Jedes der Projekte hatte einige NuGet-Pakete. In einem Projekt hatte ich eine Version des Semantic Logging-Pakets der Enterprise Library, und in zwei anderen Projekten (die auf das erste verweisen) hatte ich ältere Versionen desselben Pakets. Alles wird ohne Fehler kompiliert, aber es gab einen mysteriösen Fehler "Methode nicht gefunden", als ich versuchte, das Paket zu verwenden.

Das Update bestand darin, die alten NuGet-Pakete aus den beiden Projekten zu entfernen, sodass sie nur in dem einen Projekt enthalten waren, das sie tatsächlich benötigte. (Außerdem habe ich die gesamte Lösung sauber umgebaut.)

Überprüfen Sie Ihre Referenzen!

Stellen Sie sicher, dass Sie in Ihren Lösungsprojekten konsistent auf dieselben Bibliotheken von Drittanbietern verweisen (vertrauen Sie nicht nur den Versionen, sondern sehen Sie sich den Pfad an).

Wenn Sie beispielsweise iTextSharp v.1.00.101 in einem Projekt verwenden und NuGet verwenden oder iTextSharp v1.00.102 an einer anderen Stelle referenzieren, werden diese Arten von Laufzeitfehlern angezeigt, die irgendwie in Ihren Code gelangen.

Ich habe meinen Verweis auf iTextSharp in allen drei Projekten geändert, um auf dieselbe DLL zu verweisen, und alles hat funktioniert.

Stellen Sie bei der Entwicklung mit Ihrem eigenen NuGet-Server sicher, dass alle Assembly-Versionen identisch sind:

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

Versuchen Sie auch, Ihre Projekte oder Lösungen zu "bereinigen" und neu zu erstellen!

Haben Sie versucht, das Gerät aus- und wieder einzuschalten? Spaß beiseite, der Neustart meines Computers war das, was mir tatsächlich geholfen hat und wird in keiner der anderen Antworten erwähnt.

Ich hatte gerade dieses Problem und es stellte sich heraus, dass ich auf eine frühere Version der DLL aus meinem UI-Projekt verwies. Daher war es beim Kompilieren glücklich. Beim Ausführen wurde jedoch die vorherige Version der DLL verwendet.

Überprüfen Sie die Referenzen aller anderen Projekte, bevor Sie davon ausgehen, dass Sie Ihre Lösungen neu erstellen / bereinigen / erneut bereitstellen müssen.

In meinem Fall war es ein Problem beim Kopieren / Einfügen. Ich habe irgendwie einen privaten Konstruktor für mein Mapping-Profil gefunden:

using AutoMapper;

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

(Beachten Sie das fehlende "Publikum" vor dem Ctor)

was perfekt kompiliert wurde, aber wenn AutoMapper versucht, das Profil zu instanziieren, kann es (natürlich!) den Konstruktor nicht finden!

Ich hatte ein ähnliches Szenario, in dem dieselbe Ausnahme ausgelöst wurde. Ich hatte zwei Projekte in meiner Webanwendungslösung, zum Beispiel DAL und DAL.CustSpec. Das DAL-Projekt hatte eine Methode namens Method1, DAL.CustSpec jedoch nicht. Mein Hauptprojekt hatte einen Verweis auf das DAL-Projekt und auch einen Verweis auf ein anderes Projekt namens AnotherProj. Mein Hauptprojekt hat Method1 aufgerufen. Das AnotherProj-Projekt hatte einen Verweis auf das DAL.CustSpec-Projekt und nicht auf das DAL-Projekt. In der Build-Konfiguration waren sowohl das DAL- als auch das DAL.CustSpec-Projekt zum Erstellen konfiguriert. Nachdem alles erstellt wurde, hatte mein Webanwendungsprojekt die Assemblys AnotherProj und DAL im Ordner Bin. Als ich die Website ausführte, enthielt der temporäre ASP.NET-Ordner für die Website die DAL.CustSpec-Assembly in seinen Dateien und nicht die DAL-Assembly. aus irgendeinem Grund. Als ich den Teil mit der Bezeichnung Methode1 ausführte, erhielt ich natürlich den Fehler "Methode nicht gefunden".

Um diesen Fehler zu beheben, musste ich die Referenz im AnotherProj-Projekt von DAL.CustSpec in nur DAL ändern, alle Dateien im Ordner Temporäre ASP.NET-Dateien löschen und dann die Website erneut durchsuchen. Danach fing alles an zu arbeiten. Ich habe auch sichergestellt, dass das DAL.CustSpec-Projekt nicht erstellt wurde, indem ich es in der Build-Konfiguration deaktiviert habe.

Ich dachte, ich würde dies teilen, falls es in Zukunft jemand anderem hilft.

Ich bin auf meiner ASP.NET-Website auf dieselbe Situation gestoßen. Ich habe die veröffentlichten Dateien gelöscht, VS neu gestartet, das Projekt bereinigt und neu erstellt. Nach der nächsten Veröffentlichung war der Fehler verschwunden ...

Ich habe dieses Problem gelöst, indem ich mit meinen Änderungen ein Regalset erstellt und TFS Power Tools in meinem Arbeitsbereich "scorch" ausgeführt habe ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Dann habe ich die Änderungen aufgehoben und das Projekt neu kompiliert. Auf diese Weise bereinigen Sie alle "hängenden Partys", die sich möglicherweise in Ihrem Arbeitsbereich befinden, und starten mit einer neuen. Dies setzt natürlich voraus, dass Sie TFS verwenden.

Es ist auch möglich, dass das Problem bei einem Parameter oder Rückgabetyp der Methode liegt, die als fehlend gemeldet wurde, und die "fehlende" Methode an sich ist in Ordnung.

Genau das geschah in meinem Fall, und die irreführende Nachricht ließ es viel länger dauern, das Problem herauszufinden. Es stellte sich heraus, dass die Assembly für den Typ eines Parameters im GAC eine ältere Version hatte, die ältere Version jedoch aufgrund einer Änderung der verwendeten Versionsnummerierungsschemata tatsächlich eine höhere Versionsnummer hatte. Das Entfernen dieser älteren / höheren Version aus dem GAC hat das Problem behoben.

Verwenden von Costura.Fody 1.6 und 2.0:
Nachdem ich einige Zeit damit verbracht hatte, diese Art von Fehler mit allen anderen potenziellen Lösungen zu untersuchen, die nicht funktionierten, stellte ich fest, dass sich eine ältere Version der DLL, die ich einbettete, in demselben Verzeichnis befand, in dem ich meine ausgeführt habe neu kompilierte .exe von. Anscheinend sucht es zuerst nach einer lokalen Datei im selben Verzeichnis und dann nach innen zu seiner eingebetteten Bibliothek. Das Löschen der alten DLL hat funktioniert.

Es war nicht so, dass mein Verweis auf eine alte DLL zeigte, sondern dass sich eine Kopie einer alten DLL in dem Verzeichnis befand, von dem aus ich meine Anwendung auf einem anderen System als dem getestet habe, auf dem sie kompiliert wurde.

In meinem Fall war es ein Ordner mit älteren DLLs mit demselben Namen, auf die in meiner .csproj-Datei verwiesen wurde, obwohl der Pfad explizit angegeben wurde. Sie waren irgendwie enthalten, daher standen die verschiedenen Versionen derselben DLLs in Konflikt.

Falls das Problem durch eine alte Version der Assembly im GAC verursacht wird .
Dies kann helfen: Gewusst wie: Entfernen einer Assembly aus dem globalen Assemblycache .

In meinem Fall war die MissingMethodException für eine Methode, die sich in derselben Datei befand!

Ich hatte jedoch gerade ein NuGet-Paket hinzugefügt, das .Net Standard2 zu meinem 4.7.1-Targeting-Projekt verwendet, was zu einem Versionskonflikt für System.Net.Http (4.7.1: Version 4.0.0.0, das NuGet-Paket mit .NET) führte Standard 2 will 4.2.0.0). Dies scheinen bekannte Probleme zu sein, die in 4.7.2 besser sein sollten (siehe Anmerkung 2) .

Ich hatte in allen anderen Projekten eine solche verbindliche Weiterleitung verwendet, da es Ausnahmen gab, sobald versucht wurde, die Version 4.2.0.0 zu laden, die ich nicht hatte:

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

Außer in diesem einen Projekt, in dem anscheinend versucht wird, System.Net.Http nur zu laden, während eine lokale Funktion aufgerufen wird, die eine System.Net.Http.HttpResponseMessage als Parameter oder Rückgabetyp verwendet (Parameter während des Debuggens, Rückgabetyp, wenn ich ausgeführt werde die Tests ohne den Debugger, auch etwas seltsam). Und anstatt eine Meldung anzuzeigen, dass die Version 4.2.0.0 von System.Net.Http nicht geladen werden konnte, wird diese Ausnahme zurückgegeben.

Dies passierte mir mit MVC4 und ich entschied mich nach dem Lesen dieses Threads, das Objekt umzubenennen, das den Fehler auslöste.

Ich habe eine Reinigung und einen Umbau durchgeführt und festgestellt, dass zwei Projekte übersprungen wurden. Als ich eine davon neu erstellte, gab es einen Fehler, bei dem ich eine Funktion gestartet und nicht beendet hatte.

VS bezog sich also auf ein Modell, das ich umgeschrieben hatte, ohne mich zu fragen, ob ich das tun wollte.

Nur für den Fall, dass es jemandem hilft, obwohl es ein altes Problem ist, war mein Problem etwas seltsam.

Ich hatte diesen Fehler bei der Verwendung von Jenkins.

Schließlich stellte sich heraus, dass das Systemdatum manuell auf ein zukünftiges Datum festgelegt wurde, wodurch die DLL mit diesem zukünftigen Datum kompiliert wurde. Als das Datum wieder auf normal gesetzt wurde, interpretierte MSBuild, dass die Datei neuer war und keine Neukompilierung des Projekts erforderlich war.

Ich bin auf dieses Problem gestoßen, und für mich war es ein Projekt, das eine Liste im Beispiel-Sensor-Namespace verwendete, und ein anderer Typ implementierte die ISensorInfo-Schnittstelle. Klasse Type1SensorInfo, aber diese Klasse war eine Ebene tiefer im Namespace von Example.Sensors.Type1. Beim Versuch, Type1SensorInfo in die Liste zu deserialisieren, wurde die Ausnahme ausgelöst. Als ich mit Example.Sensors.Type1 zur ISensorInfo-Schnittstelle hinzugefügt habe, gibt es keine Ausnahme mehr!

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() 
    }
}

Ich hatte das gleiche Problem, als im Hintergrund eine Reihe von MSBuild-Prozessen ausgeführt wurden, die effektiv abgestürzt waren (sie hatten Verweise auf alte Codeversionen). Ich habe VS geschlossen und alle MSBuild-Prozesse im Prozess-Explorer beendet und dann neu kompiliert.

Ich hatte ein Testprojekt, das auf zwei andere Projekte verweist, die jeweils auf verschiedene Versionen (an verschiedenen Orten) derselben DLL verweisen. Dies verwirrte den Compiler.

In meinem Fall verwendete spotify.exe denselben Port, den mein Web-API-Projekt auf einem Entwicklungscomputer verwenden wollte. Die Portnummer war 4381.

Ich habe Spotify beendet und alles hat wieder gut funktioniert :)

Ich hatte dieses Problem, als die Methode einen Parameter benötigte, den ich nicht spezifizierte

In meinem Fall gab es überhaupt keine Codeänderung und plötzlich bekam einer der Server diese und nur diese Ausnahme (alle Server haben den gleichen Code, aber nur einer hatte Probleme):

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

Stapel:

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)

Das Problem, von dem ich glaube, dass es AppPool beschädigt hat - wir haben das AppPool-Recycling jeden Tag um 3 Uhr morgens automatisiert. Das Problem begann um 3 Uhr morgens und endete am nächsten Tag von selbst um 3 Uhr morgens.

Muss ein Referenzfehler von Microsoft sein.

Ich habe alle meine Bibliotheken gesäubert, neu erstellt und immer noch das gleiche Problem und konnte dieses Problem nicht lösen.

Ich habe lediglich die Visual Studio-Anwendung geschlossen und erneut geöffnet. Das hat funktioniert.

Es ist sehr frustrierend, dass die Behebung eines so einfachen Problems so lange dauern kann, weil Sie nicht glauben würden, dass es so etwas sein wird.

In meinem Fall bezog sich mein Projekt auf Microsoft.Net.Compilers.2.10.0. Als ich es Microsoft.Net.Compilers.2.7.0umstellte, ging der Fehler weg. Was für ein mysteriöser Fehler mit so vielen Ursachen.