System.MissingMethodException: método não encontrado?

O que antes estava funcionando no meu aplicativo de formulários da web asp.net agora gera esse erro:

System.MissingMethodException: método não encontrado

O DoThismétodo está na mesma classe e deve funcionar.

Eu tenho um manipulador genérico como tal:

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

    public void DoThis()
    {
    //
    }
}

Este é um problema que pode ocorrer quando há uma versão antiga de uma DLL ainda em algum lugar. Verifique se os assemblies mais recentes estão implantados e se nenhum assemblies antigos duplicados estão ocultos em determinadas pastas. Sua melhor aposta seria excluir todos os itens criados e reconstruir / reimplementar toda a solução.

⚠️ Versão errada do pacote Nuget ⚠️

Eu tinha um projeto de teste de unidade que estava puxando o pacote de acesso a dados interno do EF Nuget de nossas empresas e esse código puxado em um pacote externo cuja versão estava muito atrás da versão atual.

O problema foi que as configurações de Nuget para o pacote foram definidas como least version; e a versão mais antiga venceu e foi usada durante as operações ....

Portanto, ele silenciosamente obteve a versão errada para um assembly comum usado pelo pacote e pelo aplicativo.

💡 Solução 💡

Configurando / atualizando o pacote no Nuget para usar e [obter] o mais recente , foi corrigido o problema.

Resolvi esse problema instalando a versão correta do .NET Framework no servidor. O site estava em execução na versão 4.0 e o assembly para o qual estava chamando foi compilado para 4.5. Após a instalação do .NET Framework 4.5 e a atualização do site para 4.5, tudo funciona bem.

Reiniciar o Visual Studio realmente corrigiu isso para mim. Eu estou pensando que foi causado por arquivos de montagem antigos ainda em uso, e executar um "Clean Build" ou reiniciar o VS deve corrigi-lo.

Isso aconteceu comigo com um arquivo referenciado no mesmo assembly, e não uma dll separada. Depois de excluir o arquivo do projeto e incluí-lo novamente, tudo funcionou bem.

Acabei de encontrar isso em um projeto .NET MVC. A causa raiz foi versões conflitantes dos pacotes NuGet. Eu tive uma solução com vários projetos. Cada um dos projetos tinha alguns pacotes NuGet. Em um projeto, eu tinha uma versão do pacote Enterprise Log Semantic Logging, e em outros dois projetos (que fazem referência ao primeiro), eu tinha versões mais antigas do mesmo pacote. Tudo é compilado sem erros, mas ocorreu um erro misterioso "Método não encontrado" quando tentei usar o pacote.

A correção foi remover os pacotes antigos do NuGet dos dois projetos, para que fossem incluídos apenas no projeto que realmente precisava. (Também fiz uma reconstrução limpa de toda a solução.)

Verifique suas referências!

Certifique-se de que você esteja apontando consistentemente para as mesmas bibliotecas de terceiros (não confie apenas nas versões, observe o caminho) nos seus projetos de soluções.

Por exemplo, se você usar o iTextSharp v.1.00.101 em um projeto e o NuGet ou referenciar o iTextSharp v1.00.102 em outro lugar, você obterá esses tipos de erros de tempo de execução que de alguma forma aparecem no seu código.

Alterei minha referência ao iTextSharp em todos os 3 projetos para apontar para a mesma DLL e tudo funcionou.

Se estiver desenvolvendo com seu próprio servidor NuGet, verifique se as versões do assembly são iguais:

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

também .. tente "limpar" seus projetos ou solução e reconstrua novamente!

Você já tentou desligar e ligar novamente? Brincadeiras à parte, reiniciar o computador foi o que realmente fez o truque para mim e não é mencionado em nenhuma das outras respostas.

Acabei de ter esse problema e constatou-se que era porque eu estava fazendo referência a uma versão anterior da DLL do meu projeto de interface do usuário. Portanto, ao compilar, foi feliz. Mas, ao executá-lo, estava usando a versão anterior da DLL.

Verifique as referências em todos os outros projetos antes de assumir que você precisa reconstruir / limpar / reimplementar suas soluções.

No meu caso, foi um problema de copiar / colar. De alguma forma, acabei com um construtor PRIVATE para o meu perfil de mapeamento:

using AutoMapper;

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

(observe o "público" ausente na frente do ctor)

que compilou perfeitamente, mas quando o AutoMapper tenta instanciar o perfil, ele não consegue (é claro!) encontrar o construtor!

Eu tive um cenário semelhante em que estava recebendo a mesma exceção. Eu tinha dois projetos em minha solução de aplicativo da web, chamados, por exemplo, DAL e DAL.CustSpec. O projeto DAL tinha um método chamado Method1, mas DAL.CustSpec não. Meu projeto principal tinha uma referência ao projeto DAL e também uma referência a outro projeto chamado AnotherProj. Meu projeto principal fez uma chamada para o Method1. O projeto AnotherProj tinha uma referência ao projeto DAL.CustSpec, e não ao projeto DAL. A configuração de compilação tinha os projetos DAL e DAL.CustSpec configurados para serem criados. Depois que tudo foi construído, meu projeto de aplicativo da Web teve os assemblies AnotherProj e DAL em sua pasta Bin. No entanto, quando executei o site, a pasta ASP.NET temporária do site tinha o assembly DAL.CustSpec em seus arquivos e não o assembly DAL, por algum motivo. Obviamente, quando executei a parte que chamava Method1, recebi o erro "Método não encontrado".

O que eu tive que fazer para corrigir esse erro foi alterar a referência no projeto AnotherProj de DAL.CustSpec para apenas DAL, excluir todos os arquivos da pasta Temporary ASP.NET Files e, em seguida, re-executar o site. Depois disso, tudo começou a funcionar. Também assegurei-me de que o projeto DAL.CustSpec não estivesse sendo construído desmarcando-o na Configuração da Compilação.

Eu pensei em compartilhar isso, caso isso ajude alguém no futuro.

Me deparei com a mesma situação no meu site ASP.NET. Excluí os arquivos publicados, reiniciei o VS, limpei e reconstruí o projeto novamente. Após a próxima publicação, o erro desapareceu ...

Resolvi esse problema criando um conjunto de prateleiras com minhas alterações e executando o 'scorch' do TFS Power Tools no meu espaço de trabalho ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Em seguida, desfiz as alterações e recompilei o projeto. Dessa forma, você limpará todas as "festas suspensas" que possam estar presentes no seu espaço de trabalho e iniciará uma nova. Isso requer, é claro, que você esteja usando o TFS.

Também é possível que o problema esteja com um parâmetro ou tipo de retorno relatado como ausente, e o método "ausente" em si esteja correto.

Foi o que estava acontecendo no meu caso, e a mensagem enganosa levou muito mais tempo para descobrir o problema. Acontece que o assembly para o tipo de parâmetro tinha uma versão mais antiga no GAC, mas a versão mais antiga realmente tinha um número de versão mais alto devido a uma alteração nos esquemas de numeração de versão usados. A remoção da versão anterior / superior do GAC corrigiu o problema.

Usando o Costura.Fody 1.6 e 2.0:
Depois de perder muito tempo pesquisando esse mesmo tipo de erro com todas as outras soluções em potencial não funcionando, descobri que uma versão mais antiga da DLL que eu estava incorporando estava no mesmo diretório em que estava executando o meu .exe compilado recentemente. Aparentemente, ele procura primeiro um arquivo local no mesmo diretório e depois olha para a sua biblioteca incorporada. A exclusão da antiga DLL funcionou.

Para ficar claro, não era que minha referência estivesse apontando para uma DLL antiga, era que uma cópia de uma DLL antiga estava no diretório em que eu estava testando meu aplicativo em um sistema separado daquele em que foi compilado.

No meu caso, era uma pasta com DLLs mais antigas com o mesmo nome que aquelas que foram referenciadas no meu arquivo .csproj, embora o caminho tenha sido explicitamente indicado, de alguma forma foram incluídas, portanto, as várias versões das mesmas DLLs estavam em conflito.

Caso o problema seja causado por uma versão antiga do assembly no GAC .
Isso pode ajudar: Como: Remover um assembly do cache global de assemblies .

No meu caso, o MissingMethodException era para um método que estava no mesmo arquivo!

No entanto, acabei de adicionar um pacote NuGet que usa o .Net Standard2 ao meu projeto de segmentação 4.7.1, o que causou um conflito de versão para o System.Net.Http (4.7.1: versão 4.0.0.0, o pacote NuGet usando o .NET O padrão 2 quer 4.2.0.0). Parece haver problemas conhecidos que devem ser melhores na versão 4.7.2 (consulte a nota 2) .

Eu tinha usado um redirecionamento de ligação como este em todos os outros projetos, porque havia exceções assim que ele tentou carregar o 4.2.0.0 que eu não tinha:

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

Exceto neste projeto, onde parece que ele tenta carregar o System.Net.Http apenas ao chamar uma função local que usa um System.Net.Http.HttpResponseMessage como parâmetro ou tipo de retorno (parâmetro durante a depuração, tipo de retorno quando executo os testes sem o depurador, também um pouco estranho). E, em vez de mostrar uma mensagem de que não foi possível carregar a versão 4.2.0.0 do System.Net.Http, ele retorna essa exceção.

Isso aconteceu comigo usando o MVC4, e decidi, depois de ler este tópico, renomear o objeto que estava lançando o erro.

Fiz uma limpeza e reconstrução e notei que estava pulando dois projetos. Quando reconstruí um deles, ocorreu um erro em que eu havia iniciado uma função e não a terminado.

Então, o VS estava fazendo referência a um modelo que eu havia reescrito sem me perguntar se eu queria fazer isso.

Caso isso ajude alguém, embora seja um problema antigo, meu problema era um pouco estranho.

Eu tive esse erro ao usar o Jenkins.

Eventualmente, descobriu que a data do sistema foi definida manualmente para uma data futura, o que causou a compilação da dll com essa data futura. Quando a data voltou ao normal, o MSBuild interpretou que o arquivo era mais recente e não exigia a recompilação do projeto.

Corri para esse problema, e o que era para mim era um projeto usando uma lista que estava no namespace Example.Sensors e outro tipo implementado a interface ISensorInfo. Classe Type1SensorInfo, mas essa classe era uma camada mais profunda no espaço para nome em Example.Sensors.Type1. Ao tentar desserializar Type1SensorInfo na lista, lançou a exceção. Quando adicionei usando Example.Sensors.Type1 na interface ISensorInfo, não há mais exceção!

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

Aconteceu o mesmo quando tive vários processos do MSBuild sendo executados em segundo plano, que foram efetivamente travados (eles tinham referências a versões antigas de código). Fechei o VS e matei todos os processos do MSBuild no Process Explorer e recompilei.

Eu tinha um projeto de teste que referencia 2 outros projetos, cada um deles referenciando versões diferentes (em locais diferentes) da mesma dll. Isso confundiu o compilador.

No meu caso, o spotify.exe estava usando a mesma porta que meu projeto de API da Web queria usar em uma máquina de desenvolvimento. O número da porta era 4381.

Saí do Spotify e tudo funcionou bem novamente :)

Eu tive esse problema quando o método exigia um parâmetro que eu não estava especificando

No meu caso, não houve alteração de código e, de repente, um dos servidores começou a receber essa e apenas essa exceção (todos os servidores têm o mesmo código, mas apenas um começou a ter problemas):

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

Pilha:

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)

Acredito que o problema foi corrompido no AppPool - nós automatizamos a reciclagem do AppPool todos os dias às 3 da manhã e o problema começou às 3 da manhã e terminou sozinho às 3 da manhã do dia seguinte.

Deve ser um bug de referência da Microsoft.

Eu limpei, reconstruí todas as minhas bibliotecas e ainda tenho o mesmo problema e não consegui resolver isso.

Tudo o que fiz foi fechar o aplicativo Visual Studio e abri-lo novamente. Isso fez o truque.

É muito frustrante que um problema tão simples possa demorar tanto para ser resolvido, porque você não pensaria que seria algo assim.

No meu caso, meu projeto estava fazendo referência Microsoft.Net.Compilers.2.10.0. Quando mudei para Microsoft.Net.Compilers.2.7.0, o erro desapareceu. Que erro misterioso com uma variedade de causas.