System.MissingMethodException: metodo non trovato?

Quello che una volta funzionava nella mia app webforms asp.net ora genera questo errore:

System.MissingMethodException: metodo non trovato

Il DoThismetodo è sulla stessa classe e dovrebbe funzionare.

Ho un gestore generico come tale:

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

    public void DoThis()
    {
    //
    }
}

Questo è un problema che può verificarsi quando esiste ancora una versione precedente di una DLL da qualche parte. Assicurarsi che vengano distribuiti gli assiemi più recenti e che in alcune cartelle non siano nascosti assiemi duplicati precedenti. La tua scommessa migliore sarebbe quella di eliminare ogni oggetto costruito e ricostruire / ridistribuire l'intera soluzione.

⚠️ Versione pacchetto Nuget errata ⚠️

Avevo un progetto di unit test che stava inserendo il pacchetto di accesso ai dati EF Nuget interno alle nostre aziende e quel codice era contenuto in un pacchetto esterno la cui versione era molto indietro rispetto alla versione corrente.

Il problema era che le impostazioni di Nuget per il pacchetto erano impostate su least version; e la versione precedente ha vinto ed è stata utilizzata durante le operazioni ....

Quindi ha ottenuto silenziosamente la versione errata per un assembly comune utilizzato sia dal pacchetto che dall'app.

💡 Soluzione 💡

Impostando / aggiornando il pacchetto in Nuget da utilizzare e [ottenere] l'ultimo , risolto il problema.

Ho risolto questo problema installando la versione corretta di .NET Framework sul server. Il sito Web era in esecuzione con la versione 4.0 e l'assembly a cui stava chiamando era compilato per 4.5. Dopo l'installazione di .NET Framework 4.5 e l'aggiornamento del sito Web a 4.5, tutto funziona correttamente.

Il riavvio di Visual Studio lo ha effettivamente risolto per me. Sto pensando che sia stato causato da vecchi file assembly ancora in uso, e l'esecuzione di un "Clean Build" o il riavvio di VS dovrebbe risolverlo.

Mi è successo questo con un file a cui si fa riferimento nello stesso assembly, non una DLL separata. Una volta escluso il file dal progetto e poi incluso di nuovo, tutto ha funzionato bene.

Mi sono appena imbattuto in questo su un progetto .NET MVC. La causa principale erano le versioni contrastanti dei pacchetti NuGet. Ho avuto una soluzione con diversi progetti. Ognuno dei progetti aveva alcuni pacchetti NuGet. In un progetto avevo una versione del pacchetto Semantic Logging di Enterprise Library e in altri due progetti (che fanno riferimento al primo) avevo versioni precedenti dello stesso pacchetto. Compila tutto senza errori, ma ha dato un misterioso errore "Metodo non trovato" quando ho provato ad usare il pacchetto.

La correzione consisteva nel rimuovere i vecchi pacchetti NuGet dai due progetti, in modo che fosse incluso solo in un progetto che ne aveva effettivamente bisogno. (Inoltre ho fatto una ricostruzione pulita dell'intera soluzione.)

Controlla i tuoi riferimenti!

Assicurati di puntare costantemente alle stesse librerie di terze parti (non fidarti solo delle versioni, guarda il percorso) attraverso i tuoi progetti di soluzioni.

Ad esempio, se si utilizza iTextSharp v.1.00.101 in un progetto e si NuGet o si fa riferimento a iTextSharp v1.00.102 da qualche altra parte, si otterranno questi tipi di errori di runtime che in qualche modo si insinuano nel codice.

Ho cambiato il mio riferimento a iTextSharp in tutti e 3 i progetti per indicare la stessa DLL e tutto ha funzionato.

Se si sviluppa con il proprio server NuGet, assicurarsi che le versioni dell'assembly siano tutte uguali:

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

inoltre .. prova a "ripulire" i tuoi progetti o la tua soluzione e ricostruisci di nuovo!

Hai provato a spegnere e riaccendere? Scherzi a parte, riavviare il mio computer è stato ciò che ha effettivamente funzionato per me e non è menzionato in nessuna delle altre risposte.

Ho appena avuto questo problema e si è scoperto che era perché stavo facendo riferimento a una versione precedente della DLL dal mio progetto UI. Pertanto, durante la compilazione è stato felice. Ma durante l'esecuzione utilizzava la versione precedente della DLL.

Controlla i riferimenti su tutti gli altri progetti prima di assumere che è necessario ricostruire / pulire / ridistribuire le soluzioni.

Nel mio caso è stato un problema di copia / incolla. In qualche modo sono finito con un costruttore PRIVATO per il mio profilo di mappatura:

using AutoMapper;

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

(prendi nota del "pubblico" mancante di fronte al ctor)

che è stato compilato perfettamente bene, ma quando AutoMapper tenta di creare un'istanza del profilo non riesce (ovviamente!) a trovare il costruttore!

Avevo uno scenario simile in cui stavo ricevendo la stessa eccezione. Avevo due progetti nella mia soluzione di applicazione web, chiamati, per esempio, DAL e DAL.CustSpec. Il progetto DAL aveva un metodo chiamato Method1, ma DAL.CustSpec no. Il mio progetto principale aveva un riferimento al progetto DAL e anche un riferimento a un altro progetto chiamato AnotherProj. Il mio progetto principale ha chiamato Call1. Il progetto AnotherProj faceva riferimento al progetto DAL.CustSpec e non al progetto DAL. La configurazione Build aveva sia i progetti DAL che DAL.CustSpec configurati per essere compilati. Dopo che tutto è stato creato, il mio progetto di applicazione web ha avuto gli assembly AnotherProj e DAL nella sua cartella Bin. Tuttavia, quando ho eseguito il sito Web, la cartella ASP.NET temporanea per il sito Web conteneva l'assembly DAL.CustSpec nei suoi file e non l'assembly DAL, per qualche ragione. Naturalmente, quando ho eseguito la parte che ha chiamato Method1, ho ricevuto un errore "Metodo non trovato".

Quello che dovevo fare per correggere questo errore era cambiare il riferimento nel progetto AnotherProj da DAL.CustSpec a DAL, eliminare tutti i file nella cartella dei file temporanei ASP.NET e quindi eseguire nuovamente il sito Web. Successivamente, tutto ha iniziato a funzionare. Mi sono anche assicurato che il progetto DAL.CustSpec non fosse stato creato deselezionandolo nella Configurazione build.

Ho pensato di condividere questo nel caso in cui aiuti qualcun altro in futuro.

Mi sono imbattuto nella stessa situazione nel mio sito Web ASP.NET. Ho cancellato i file pubblicati, riavviato VS, ripulito e ricostruito nuovamente il progetto. Dopo la prossima pubblicazione, l'errore era sparito ...

Ho risolto questo problema creando uno scaffale con le mie modifiche ed eseguendo 'scorch' di TFS Power Tools nel mio spazio di lavoro ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Quindi ho deselezionato le modifiche e ricompilato il progetto. In questo modo pulirai tutte le "feste sospese" che potrebbero trovarsi nell'area di lavoro e ne avvierai una nuova. Ciò richiede, ovviamente, che tu stia utilizzando TFS.

È anche possibile che il problema riguardi un parametro o un tipo restituito del metodo che è stato segnalato mancante e che il metodo "mancante" di per sé va bene.

È quello che stava succedendo nel mio caso e il messaggio fuorviante ha impiegato molto più tempo a capire il problema. Si scopre che l'assemblaggio per un tipo di parametro aveva una versione precedente nel GAC, ma la versione precedente aveva in realtà un numero di versione superiore a causa di una modifica degli schemi di numerazione della versione utilizzati. La rimozione di quella versione precedente / successiva dal GAC ha risolto il problema.

Usando Costura.Fody 1.6 & 2.0:
dopo aver perso un sacco di tempo a esaminare questo stesso tipo di errore con tutte le altre potenziali soluzioni che non funzionavano, ho scoperto che una versione precedente della DLL che stavo incorporando era nella stessa directory in cui stavo eseguendo il mio .exe appena compilato da. Apparentemente cerca prima un file locale nella stessa directory, quindi guarda all'interno della sua libreria incorporata. L'eliminazione della vecchia DLL ha funzionato.

Per essere chiari, non è che il mio riferimento puntava a una vecchia DLL, era che una copia di una vecchia DLL era nella directory da cui stavo testando la mia applicazione su un sistema separato da quello su cui era stata compilata.

Nel mio caso era una cartella con vecchie DLL con lo stesso nome che quelle a cui si faceva riferimento nel mio file .csproj sebbene il percorso fosse esplicitamente dato che erano in qualche modo incluse, quindi le diverse versioni delle stesse DLL erano in conflitto.

Nel caso in cui il problema sia causato da una versione precedente dell'assembly nel GAC .
Questo può aiutare: Procedura: rimuovere un assembly dalla Global Assembly Cache .

Nel mio caso, MissingMethodException era per un metodo che si trovava nello stesso file!

Tuttavia, avevo appena aggiunto un pacchetto NuGet che utilizza .Net Standard2 al mio progetto di targeting 4.7.1, che ha causato un conflitto di versione per System.Net.Http (4.7.1: versione 4.0.0.0, il pacchetto NuGet utilizzando .NET Lo standard 2 vuole 4.2.0.0). Questo sembra essere noto problemi che dovrebbero essere migliori in 4.7.2 (vedi nota 2) .

Avevo usato un reindirizzamento vincolante come questo in tutti gli altri miei progetti, perché c'erano delle eccezioni non appena ho provato a caricare la 4.2.0.0 che non avevo:

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

Tranne in questo progetto, in cui sembra che tenta di caricare System.Net.Http solo mentre chiama una funzione locale che utilizza System.Net.Http.HttpResponseMessage come parametro o tipo di ritorno (parametro durante il debug, tipo di ritorno quando corro i test senza il debugger, anche un po 'strano). E invece di mostrare un messaggio che non è possibile caricare la versione 4.2.0.0 di System.Net.Http, restituisce questa eccezione.

Questo mi è successo usando MVC4, e dopo aver letto questo thread ho deciso di rinominare l'oggetto che stava generando l'errore.

Ho fatto un lavoro pulito e ricostruito e ho notato che stava saltando due progetti. Quando ho ricostruito uno di essi, si è verificato un errore in cui avevo avviato una funzione e non l'avevo completata.

Quindi VS faceva riferimento a un modello che avevo riscritto senza chiedermi se volevo farlo.

Nel caso in cui aiuti qualcuno, anche se è un vecchio problema, il mio problema era un po 'strano.

Ho avuto questo errore durante l'utilizzo di Jenkins.

Alla fine ho scoperto che la data di sistema è stata impostata manualmente su una data futura, che ha causato la compilazione della dll con quella data futura. Quando la data è stata riportata alla normalità, MSBuild ha interpretato che il file era più recente e non richiedeva la ricompilazione del progetto.

Mi sono imbattuto in questo problema, e per me era un progetto che utilizzava un Elenco che era nello spazio dei nomi Esempio. Sensori e un altro tipo implementava l'interfaccia ISensorInfo. Classe Type1SensorInfo, ma questa classe era un livello più profondo nello spazio dei nomi in Example.Sensors.Type1. Quando ha cercato di deserializzare Type1SensorInfo nell'elenco, ha generato l'eccezione. Quando ho aggiunto usando Example.Sensors.Type1 nell'interfaccia ISensorInfo, non ci sono più eccezioni!

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

Ho avuto la stessa cosa accadendo quando avevo in esecuzione un certo numero di processi MSBuild in background che si erano effettivamente arrestati in modo anomalo (avevano riferimenti a vecchie versioni di codice). Ho chiuso VS e ucciso tutti i processi di MSBuild in Process Explorer e poi ricompilato.

Ho avuto un progetto di test che fa riferimento ad altri 2 progetti a cui ognuno ha fatto riferimento versioni diverse (in posizioni diverse) della stessa dll. Questo ha confuso il compilatore.

Nel mio caso spotify.exe utilizzava la stessa porta che il mio progetto API Web voleva utilizzare su una macchina di sviluppo. Il numero di porta era 4381.

Ho lasciato Spotify e tutto ha funzionato di nuovo bene :)

Ho avuto questo problema quando il metodo richiedeva un parametro che non stavo specificando

Nel mio caso, non vi è stata alcuna modifica del codice e improvvisamente uno dei server ha iniziato a ottenere questo e solo questa eccezione (tutti i server hanno lo stesso codice, ma solo uno ha iniziato ad avere problemi):

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

Pila:

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)

Il problema che ritengo fosse AppPool corrotto: abbiamo automatizzato il riciclaggio di AppPool in corso ogni giorno alle 3 del mattino e il problema è iniziato alle 3 del mattino e poi si è concluso da solo alle 3 del giorno successivo.

Deve essere un bug di riferimento di Microsoft.

Ho pulito, ricostruito su tutte le mie librerie e ho ancora avuto lo stesso problema e non sono riuscito a risolverlo.

Tutto quello che ho fatto è stato chiudere l'applicazione Visual Studio e riaprirla. Questo ha funzionato.

È molto frustrante che un problema così semplice possa richiedere così tanto tempo perché non penseresti che sarà qualcosa del genere.

Nel mio caso, il mio progetto faceva riferimento Microsoft.Net.Compilers.2.10.0. Quando l'ho passato a Microsoft.Net.Compilers.2.7.0, l'errore è andato via. Che errore misterioso con una tale varietà di cause.