it-swarm.com.de

System.MissingMethodException: Methode nicht gefunden?

Was in meiner asp.net webforms App einmal funktioniert hat, wirft jetzt diesen Fehler ab:

System.MissingMethodException: Methode nicht gefunden

Die DoThis-Methode 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()
    {
    //
    }
}
187
user603007

Dies ist ein Problem, das auftreten kann, wenn eine alte Version von DLL noch irgendwo in der Umgebung verweilt. Stellen Sie sicher, dass die neuesten Assemblys bereitgestellt werden und sich keine doppelten älteren Assemblys in bestimmten Ordnern verstecken. Am besten löschen Sie jedes erstellte Element und stellen die gesamte Lösung wieder her.

309
Polity

Ich habe dieses Problem durch Installieren der korrekten .NET Framework-Version auf dem Server behoben. Die Website lief unter Version 4.0 und die Assembly, für die sie aufgerufen wurde, 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.

19
Ben Gripka

Durch den Neustart von Visual Studio wurde es tatsächlich behoben. Ich denke, es wurde durch alte Assembly-Dateien verursacht, die noch verwendet werden, und das Ausführen eines "Clean Build" oder Neustarts von VS sollte dies beheben.

18
Jelani

Falsche Nuget-Paketversion

Ich hatte ein Unit-Test-Projekt, das unser EF-Nuget-Datenzugriffspaket für Unternehmen in die Höhe zog, und diese Version war Weg hinter der aktuellen Version. 

Nuget-Einstellungen für das zuvor erwähnte Paket wurden auf dieleast versionfür diese andere Pakete gesetzt die die von der zweiten Ebene abhängigen Pakete waren.

Daher ist es hat still die falsche Version für eine verwandte Versammlung erhalten.

Lösung

Durch Setzen/Aktualisieren des Pakets in Nuget auf [das neueste] abrufen Problem behoben.

14
ΩmegaMan

Ich bin gerade auf ein .NET MVC-Projekt 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 Enterprise Library Semantic Logging-Pakets, und in zwei anderen Projekten (die sich auf das erste Projekt beziehen) hatte ich ältere Versionen des gleichen Pakets. Es wird alles ohne Fehler kompiliert, aber beim Versuch, das Paket zu verwenden, wurde ein mysteriöser Fehler "Methode nicht gefunden" ausgegeben.

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

5
Mark Meuer

Ich hatte das mit einer Datei, auf die in derselben Assembly verwiesen wurde, nicht in einer separaten DLL. Nachdem ich die Datei aus dem Projekt ausgeschlossen und dann wieder eingefügt hatte, funktionierte alles einwandfrei.

5
Josh Noe

Überprüfen Sie Ihre Referenzen! 

Stellen Sie sicher, dass Sie in allen Ihren Lösungsprojekten durchgängig auf dieselben Drittanbieter-Bibliotheken zeigen (vertrauen Sie nicht nur Versionen, schauen Sie sich den Pfad an). 

Wenn Sie beispielsweise iTextSharp v.1.00.101 in einem Projekt verwenden und Sie NuWet oder iTextSharp v1.00.102 an einer anderen Stelle angeben, werden diese Laufzeitfehler angezeigt, die sich irgendwie in Ihren Code einschleichen. 

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

4
Juls

Wenn Sie mit Ihrem eigenen NuGet-Server entwickeln, stellen Sie sicher, dass die Assembly-Versionen alle gleich sind:

[Assembly: AssemblyVersion("0.2.6")]
[Assembly: AssemblyFileVersion("0.2.6")]
[Assembly: AssemblyInformationalVersion("0.2.6")]
4
sennett

versuchen Sie auch, Ihre Projekte oder Ihre Lösung zu "reinigen" und sie erneut aufzubauen!

3
user384080

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

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

2
Jamie Lupton

Haben Sie versucht, das Gerät auszuschalten und wieder einzuschalten? Spass beiseite: Der Neustart meines Computers war für mich eigentlich der Trick und wird in keiner der anderen Antworten erwähnt.

1
Lee Bailey

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

1
Irshu

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

So geschah es in meinem Fall, und aufgrund der irreführenden Nachricht dauerte es viel länger, bis das Problem geklärt war. Es stellte sich heraus, dass die Assembly für einen Parametertyp eine ältere Version im GAC hatte, die ältere Version hatte jedoch aufgrund einer Änderung der verwendeten Versionsnummerierungsschemata tatsächlich eine höhere Versionsnummer. Das Entfernen dieser älteren/höheren Version aus dem GAC hat das Problem behoben.

1
Jimmy

Ich löste dieses Problem, indem ich ein Regal mit meinen Änderungen erstellte und TFS Power Tools "scorch" in meinem Arbeitsbereich ausführte ( https://visualstudiogallery.msdn.Microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Dann habe ich die Änderungen aufgehoben und das Projekt erneut kompiliert. Auf diese Weise bereinigen Sie eventuell vorhandene "hängende Partys" in Ihrem Arbeitsbereich und starten mit einem neuen Start. Dies erfordert natürlich, dass Sie verwenden TFS.

1
fbastian

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

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!

1
DaBeSoft

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 .

1
Ymagine First

Ich hatte ein ähnliches Szenario, in dem diese Ausnahme ausgelöst wurde. Ich hatte zwei Projekte in meiner Webanwendungslösung, genannt 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 mit dem Namen AnotherProj. Mein Hauptprojekt rief Method1 an. Das AnotherProj-Projekt hatte einen Verweis auf das DAL.CustSpec-Projekt und nicht auf das DAL-Projekt. In der Build-Konfiguration konnten sowohl das DAL- als auch das DAL.CustSpec-Projekt konfiguriert werden. Nachdem alles erstellt wurde, hatte mein Webanwendungsprojekt die Assemblys AnotherProj und DAL im Ordner Bin. Als ich die Website ausführte, hatte der temporäre ASP.NET-Ordner für die Website aus irgendeinem Grund die DAL.CustSpec-Assembly in den Dateien und nicht die DAL-Assembly. Als ich den Teil mit dem Namen Method1 ausgeführt habe, erhielt ich natürlich den Fehler "Methode nicht gefunden".

Um diesen Fehler zu beheben, musste ich den Verweis im AnotherProj-Projekt von DAL.CustSpec in DAL ändern, alle Dateien im Ordner "Temporäre ASP.NET-Dateien" löschen und die Website anschließend erneut aufrufen. Danach fing alles an zu arbeiten. Ich stellte auch sicher, dass das DAL.CustSpec-Projekt nicht erstellt wurde, indem es in der Build-Konfiguration deaktiviert wurde.

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

1
Ron Kanagy

Verwendung von Costura.Fody 1.6 & 2.0:
Nachdem ich eine Menge Zeit damit verbracht hatte, nach demselben Fehler zu suchen, bei dem alle anderen potenziellen Lösungen nicht funktionierten, stellte ich fest, dass eine ältere Version der DLL, die ich einbettete, in demselben Verzeichnis lag, in dem ich mein neues ausführte kompilierte .exe aus. 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.

Um klar zu sein, es war nicht so, dass mein Verweis auf eine alte DLL verweist, sondern dass sich eine Kopie einer alten DLL in dem Verzeichnis befand, von dem aus ich meine Anwendung auf einem anderen System als dem testete, das es war zusammengestellt am.

1
grep 65535

Für den Fall, dass es jedem 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 gesetzt wurde, wodurch die DLL mit diesem zukünftigen Datum kompiliert wurde. Als das Datum auf Normal zurückgesetzt wurde, interpretierte MSBuild, dass die Datei neuer war und keine Neukompilierung des Projekts erforderlich war.

0

Ich bin auf dieses Problem gestoßen, und für mich war ein Projekt eine List, die sich im Namespace von Example.Sensors befand, und ein anderer Typ implementierte die ISensorInfo-Schnittstelle. Klasse Type1SensorInfo, diese Klasse befand sich jedoch um eine Ebene tiefer im Namespace von Example.Sensors.Type1. Beim Versuch, Type1SensorInfo in der Liste zu deserialisieren, wurde die Ausnahme ausgelöst. Beim Hinzufügen von Example.Sensors.Type1 zur ISensorInfo-Schnittstelle 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() 
    }
}
0
Steven Koxlien

In meinem Fall handelte es sich um einen Ordner mit älteren DLLs mit demselben Namen, auf die in meiner .csproj-Datei verwiesen wurde, obwohl der Pfad explizit angegeben wurde, dass sie irgendwie enthalten waren. Daher standen die verschiedenen Versionen derselben DLLs in Konflikt. 

Ich hatte dieses Problem, als für die Methode ein Parameter erforderlich war, den ich nicht angegeben habe 

0
R2D2

In meinem Fall verwies mein Projekt auf Microsoft.Net.Compilers.2.10.0. Als ich auf Microsoft.Net.Compilers.2.7.0 umgestellt habe, ging der Fehler weg. Was für ein mysteriöser Fehler bei einer Vielzahl von Ursachen. 

0
jaycer

Muss ein Referenzfehler von Microsoft sein.

Ich habe alle meine Bibliotheken bereinigt, neu aufgebaut und habe immer noch das gleiche Problem und konnte dieses Problem nicht lösen.

Alles was ich tat, war die Visual Studio-Anwendung zu schließen und wieder zu öffnen. Das hat den Trick gemacht. 

Es ist sehr frustrierend, dass ein so einfaches Problem so lange dauern kann, weil man nicht glauben würde, dass es so etwas sein wird.

0
JayJay Barnard

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

Meines Erachtens war AppPool beschädigt. Wir haben AppPool-Recycling täglich um 3 Uhr morgens automatisiert. Die Ausgabe begann um 3 Uhr morgens und endete dann am nächsten Tag um 3 Uhr morgens.

0
George

In meinem Fall verwendete spotify.exe den gleichen 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 :)

0
Arda Basoglu

Ich hatte dasselbe passiert, als ich eine Reihe von MSBuild-Prozessen im Hintergrund hatte, die effektiv abgestürzt waren (sie hatten Verweise auf alte Versionen von Code). Ich habe VS geschlossen und alle MSBuild-Prozesse im Prozess-Explorer abgebrochen und neu kompiliert.

0
bytedev

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

0
nuander

Dies geschah bei mir mit MVC4, und ich entschied mich nach dem Lesen dieses Threads, das Objekt umzubenennen, das den Fehler ausgelöst hat.

Ich machte einen sauberen und umgebauten Aufbau und stellte fest, dass zwei Projekte übersprungen wurden. Als ich eine von ihnen neu aufbaute, 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 wollte.

0
TheWizardOfTN