System.MissingMethodException: Methode nicht gefunden?

244

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()
    {
    //
    }
}
user603007
quelle
Kannst du etwas mehr Code posten, da dieser Code nicht gültig ist?
Mironych
2
Was ist somepage? Wie 'Sound' bemerkt, ist dieser Code nicht gültig. Bitte geben Sie uns einen vollständigen Code-Ausschnitt, der das Problem demonstriert.
Amy

Antworten:

387

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.

Gemeinwesen
quelle
62
Stellen Sie insbesondere sicher, dass sich keine alte Version im GAC befindet.
Beladung
7
Wenn Sie in einem unglücklichen Fall arbeiten, in dem Sie eine Bibliothek haben, die von einer Bibliothek abhängt, die von einer Bibliothek abhängt usw. Stellen Sie dann sicher, dass Sie alle abhängigen Bibliotheken mit derselben Version der DLL bereinigen / neu erstellen. NHibernate in meinem Fall ...
Serj Sagan
2
Durch Aktualisieren des .NET-Zielframeworks für das Projekt kann der Fehler ebenfalls behoben werden. Ich habe ein MVC4 / Web API 1-Projekt für .NET 4.5 aktualisiert. Nach dem Upgrade aller MVC-, Web-API- und Entity Framework-Abhängigkeiten trat der gleiche Fehler auf. Durch Ändern des Zielframeworks in .NET 4.5.1 wurde der Fehler behoben.
Sergey K
1
Es ist mir passiert, als ich nur eine geänderte exe-Datei bereitgestellt und keine Hilfs-DLL bereitgestellt habe, weil sie keine Codeänderung hatte - aber sie wurde neu erstellt. Ich habe diese neu erstellte DLL bereitgestellt und der Fehler ist verschwunden. Ich habe andere Bereitstellungen durchgeführt, ohne eine ansonsten unveränderte DLL erneut bereitzustellen, und hatte keine Probleme. Daher bin ich mir immer noch nicht sicher, was genau hier passiert ist. Ich denke, das Sicherste ist, eine neu erstellte Datei bereitzustellen, unabhängig davon, ob zugrunde liegende Codeänderungen vorliegen oder nicht.
Ho Ho Ho
14
Ich fand es nützlich, beim Debuggen das Fenster Debug -> Windows -> Module zu öffnen, um zu sehen, von wo die Assembly geladen wurde.
JamesD
31

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

ΩmegaMan
quelle
1
Das hat es für mich behoben. Das Verwalten der Pakete für die Lösung funktionierte nicht, aber ich musste jedes Projekt einzeln aktualisieren.
Aoakeson
Mein Unit-Test-Projekt bezog sich auf eine neue Version als mein eigentliches Projekt
Rhyous
26

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.

Ben Gripka
quelle
2
Einige Probleme mit .NET 3.5 Kompilierungsziel und installiert .NET 3. Ich frage mich wirklich, warum es beim Start keine grundlegende Warnung mehr gibt ...
Martin Meeser
Für .NET Framework-Version> 4.0 müssen Sie die Lagerhaltungseinheit (SKU) angeben. Sie gibt die Version von .NET Framework an, auf die die App abzielt. docs.microsoft.com/en-us/dotnet/framework/configure-apps/…
bgcode
21

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.

Jelani
quelle
5

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.

Josh Noe
quelle
5

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

Mark Meuer
quelle
5

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

Juls
quelle
Für mich hat es gut funktioniert, das Projekt zu bereinigen und einige Referenzen erneut zu löschen und hinzuzufügen.
Honza P.
Dies ist insbesondere bei VS 2017 ein Problem, da Sie häufig eine Referenz hinzufügen können, die den Quellpfad zum Ausgabeordner eines anderen Projekts in der Lösung und nicht zum Ausgabeordner der Referenzassembly festlegt.
Herr TA
4

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")]
Sennett
quelle
Wie soll ich das überprüfen?
SerG
Ich denke im nupkg.
Sennett
4

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

user384080
quelle
3

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.

Lee Bailey
quelle
3

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.

Jamie Lupton
quelle
2

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!

DaBeSoft
quelle
@RenaudGauthier Vielleicht habe ich bei Jon Skeets Antwort etwas falsch verstanden, aber er gibt an, dass Klassen ohne Zugriffsmodifikator intern sind, und in den Kommentaren sagt er wörtlich: "Nein, ist es nicht. Wenn Sie einen Konstruktor deklarieren und keine Barrierefreiheit angeben, wird dies der Fall sein." privat sein. Siehe Abschnitt 10.3.5 der C # -Spezifikation ". Also denke ich, mein Konstruktor ist doch privat? Bitte korrigieren Sie mich, wenn ich mich irre. Und ja, meine Antwort war nicht im Zusammenhang, ich kam von einer anderen Frage hierher (die mir keine Antwort gab). Ich werde dort auch einen Link zu meiner Antwort hinzufügen.
DaBeSoft
Sie haben absolut Recht, egal, ich habe den nutzlosen Kommentar gelöscht.
Renaud Gauthier
1

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.

Ron Kanagy
quelle
1

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

Irshu
quelle
1

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.

fbastian
quelle
1

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.

Jimmy
quelle
1

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.

grep65535
quelle
1

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.

Alexandre Daubricourt
quelle
1

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.

Legolas
quelle
0

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.

TheWizardOfTN
quelle
0

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.

Renato Chencinski
quelle
0

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() 
    }
}
Steven Koxlien
quelle
0

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.

bytedev
quelle
0

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.

Nuander
quelle
0

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

Arda Basoglu
quelle
0

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

Lord Darth Vader
quelle
0

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.

George
quelle
0

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.

JayJay Barnard
quelle
0

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.

Jaycer
quelle