System.MissingMethodException: ¿Método no encontrado?


244

Lo que antes funcionaba en mi aplicación de formularios web asp.net ahora arroja este error:

System.MissingMethodException: método no encontrado

El DoThismétodo está en la misma clase y debería funcionar.

Tengo un controlador 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()
    {
    //
    }
}

¿puedes publicar más código porque este código no es válido?
mironych

2
¿Qué es somepage? Como se señaló 'sonido', este código no es válido. Danos un fragmento de código completo que demuestre el problema.
Amy

Respuestas:


387

Este es un problema que puede ocurrir cuando todavía hay una versión antigua de un archivo DLL en algún lugar. Asegúrese de que los ensamblados más recientes estén implementados y que no se oculten ensamblados antiguos duplicados en ciertas carpetas. Su mejor opción sería eliminar cada elemento construido y reconstruir / volver a implementar la solución completa.


62
En particular, asegúrese de que una versión anterior no esté en el GAC.
ladenedge

77
Además, si está trabajando en el desafortunado caso en el que tiene una biblioteca que depende de una biblioteca, que depende de una biblioteca, etc. Luego, asegúrese de limpiar / reconstruir todas las bibliotecas dependientes con la misma versión de cualquier dll, NHibernate en mi caso ...
Serj Sagan

2
La actualización del marco de trabajo de .NET para el proyecto también puede corregir el error. Estaba actualizando un proyecto MVC4 / Web API 1 dirigido a .NET 4.5. Después de actualizar todas las dependencias de MVC, API web y Entity Framework, me encontré con el mismo error; cambiar el marco de destino a .NET 4.5.1 hizo que el error desapareciera.
Sergey K

1
Me sucedió cuando implementé solo un archivo exe modificado y no implementé un dll auxiliar porque no había tenido ningún cambio de código, pero había sido reconstruido. Desplegué ese dll reconstruido y el error desapareció. He realizado otras implementaciones sin volver a implementar una dll que de otro modo no habría cambiado y no tuve problemas, por lo que todavía no estoy seguro de qué sucedió exactamente aquí. Supongo que lo más seguro es implementar cualquier archivo reconstruido sin importar si tiene cambios de código subyacentes o no.
Ho Ho Ho

14
Me pareció útil abrir la ventana Depuración -> Windows -> Módulos al depurar para ver desde dónde se estaba cargando el ensamblaje.
JamesD

31

⚠️ Versión incorrecta del paquete Nuget ⚠️

Tenía un proyecto de prueba de unidad que fue tirando en nuestras empresas EF Nuget paquete de acceso de datos interna y que codifican tirado en un paquete externo cuya versión se forma detrás de la versión actual.

El problema era que la configuración de Nuget para el paquete estaba establecida en least version; y la versión anterior ganó y se usó durante las operaciones ...

Por lo tanto, silenciosamente obtuvo la versión incorrecta para un ensamblaje común utilizado tanto por el paquete como por la aplicación.


💡 Solución 💡

Al configurar / actualizar el paquete en Nuget para usar y [obtener] lo último , se solucionó el problema.


1
Esto me lo arregló. La administración de los paquetes para la solución no funcionó, pero tuve que actualizar cada proyecto individualmente.
aoakeson

Mi proyecto de prueba de unidad hacía referencia a una nueva versión que mi proyecto real
Rhyous,

26

Resolví este problema instalando la versión correcta de .NET Framework en el servidor. El sitio web se ejecutaba con la versión 4.0 y el ensamblado al que estaba llamando se compiló para 4.5. Después de instalar .NET Framework 4.5 y actualizar el sitio web a 4.5, todo funciona bien.


2
algún problema con el objetivo de compilación de .NET 3.5 e instalado .NET 3. Realmente me pregunto por qué no hay más advertencia básica al inicio ...
Martin Meeser

Para .NET Framework versión> 4.0, debe especificar la unidad de mantenimiento de inventario (SKU), indica la versión de .NET Framework a la que apunta la aplicación. docs.microsoft.com/en-us/dotnet/framework/configure-apps/…
bgcode

21

Reiniciar Visual Studio en realidad lo arregló para mí. Estoy pensando que fue causado por archivos de ensamblaje antiguos que todavía están en uso, y realizar una "compilación limpia" o reiniciar VS debería solucionarlo.


5

Esto me sucedió con un archivo al que se hace referencia en el mismo ensamblado, no con un dll separado. Una vez que excluí el archivo del proyecto y lo volví a incluir, todo funcionó bien.


5

Me encontré con esto en un proyecto .NET MVC. La causa raíz fueron las versiones conflictivas de los paquetes NuGet. Tuve una solución con varios proyectos. Cada uno de los proyectos tenía algunos paquetes NuGet. En un proyecto tenía una versión del paquete de Registro Semántico de la Biblioteca Empresarial, y en otros dos proyectos (que hacen referencia al primero) tenía versiones anteriores del mismo paquete. Todo se compila sin error, pero dio un misterioso error de "Método no encontrado" cuando intenté usar el paquete.

La solución fue eliminar los paquetes NuGet antiguos de los dos proyectos, de modo que solo se incluyera en el único proyecto que realmente lo necesitaba. (También hice una reconstrucción limpia de toda la solución).


5

¡Comprueba tus referencias!

Asegúrese de estar apuntando constantemente a las mismas bibliotecas de terceros (no solo confíe en las versiones, mire la ruta) en sus proyectos de soluciones.

Por ejemplo, si usa iTextSharp v.1.00.101 en un proyecto y NuGet o hace referencia a iTextSharp v1.00.102 en otro lugar, obtendrá este tipo de errores de tiempo de ejecución que de alguna manera se filtran en su código.

Cambié mi referencia a iTextSharp en los 3 proyectos para apuntar a la misma DLL y todo funcionó.


Para mí funcionó bien para limpiar el proyecto y eliminar y agregar algunas referencias una vez más.
Honza P.

Esto es particularmente un problema con VS 2017 porque a menudo le ofrece agregar una referencia que establece la ruta de origen a la carpeta de salida de otro proyecto en la solución, no a la carpeta de salida del ensamblaje de referencia.
Sr. TA

4

Si desarrolla con su propio servidor NuGet, asegúrese de que las versiones de ensamblaje sean todas iguales:

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

¿Cómo debo verificarlo?
SerG

Pienso en el nupkg.
sennett

4

también ... ¡trate de "limpiar" sus proyectos o soluciones y reconstruya nuevamente!


3

¿Has intentado apagarlo y volverlo a encender? Bromas aparte, reiniciar mi computadora fue lo que realmente me funcionó y no se menciona en ninguna de las otras respuestas.


3

Acabo de tener este problema y resultó que era porque estaba haciendo referencia a una versión anterior de la DLL de mi proyecto de IU. Por lo tanto, al compilar fue feliz. Pero cuando se ejecutaba usaba la versión anterior de la DLL.

Verifique las referencias en todos los demás proyectos antes de asumir que necesita reconstruir / limpiar / volver a implementar sus soluciones.


2

En mi caso fue un problema de copiar / pegar. De alguna manera terminé con un constructor PRIVADO para mi perfil de mapeo:

using AutoMapper;

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

(tome nota del "público" que falta frente al ctor)

que se compiló perfectamente bien, pero cuando AutoMapper intenta crear una instancia del perfil, ¡no puede (por supuesto!) encontrar el constructor!


@RenaudGauthier tal vez leí mal algo en la respuesta de Jon Skeets, pero él dice que las clases sin modificador de acceso son internas, y en los comentarios literalmente dice "No, no lo es. Si declaras un constructor y no especificas una accesibilidad, lo hará ser privado. Consulte la sección 10.3.5 de la especificación C # ". Entonces, ¿supongo que mi constructor es privado después de todo? Corrígeme si me equivoco. Y sí, mi respuesta estaba fuera de contexto, vine aquí de otra pregunta (que no me dio una respuesta). Agregaré un enlace a mi respuesta allí también.
DaBeSoft

Tienes toda la razón, no importa, he eliminado el comentario inútil.
Renaud Gauthier

1

Tuve un escenario similar en el que recibía esta misma excepción. Tenía dos proyectos en mi solución de aplicación web, nombrados, por ejemplo, DAL y DAL.CustSpec. El proyecto DAL tenía un método llamado Método1, pero DAL.CustSpec no. Mi proyecto principal tenía una referencia al proyecto DAL y también una referencia a otro proyecto llamado AnotherProj. Mi proyecto principal hizo una llamada al Método 1. El proyecto AnotherProj tenía una referencia al proyecto DAL.CustSpec, y no al proyecto DAL. La configuración de Build tenía los proyectos DAL y DAL.CustSpec configurados para ser construidos. Después de que todo se construyó, mi proyecto de aplicación web tenía los ensamblados AnotherProj y DAL en su carpeta Bin. Sin embargo, cuando ejecuté el sitio web, la carpeta ASP.NET temporal para el sitio web tenía el ensamblado DAL.CustSpec en sus archivos y no el ensamblado DAL, por alguna razón. Por supuesto, cuando ejecuté la parte que llamaba Método1, recibí el error "Método no encontrado".

Lo que tuve que hacer para corregir este error fue cambiar la referencia en el proyecto AnotherProj de DAL.CustSpec a solo DAL, eliminar todos los archivos en la carpeta Archivos temporales de ASP.NET y luego volver a clasificar el sitio web. Después de eso, todo comenzó a funcionar. También me aseguré de que el proyecto DAL.CustSpec no se estuviera compilando desmarcando en la Configuración de compilación.

Pensé que compartiría esto en caso de que ayude a alguien más en el futuro.


1

Encontré la misma situación en mi sitio web ASP.NET. Eliminé los archivos publicados, reinicié VS, limpié y reconstruí el proyecto nuevamente. Después de la próxima publicación, el error desapareció ...



1

También es posible que el problema sea con un parámetro o tipo de retorno del método que se informa que falta, y el método "perdido" en sí está bien.

Eso es lo que estaba sucediendo en mi caso, y el mensaje engañoso hizo que tomara mucho más tiempo resolver el problema. Resulta que el ensamblaje para un tipo de parámetro tenía una versión anterior en el GAC, pero la versión anterior en realidad tenía un número de versión más alto debido a un cambio en los esquemas de numeración de versión utilizados. La eliminación de esa versión anterior / superior del GAC solucionó el problema.


1

Usando Costura.Fody 1.6 y 2.0:
después de perder un montón de tiempo buscando este mismo tipo de error con todas las demás soluciones potenciales que no funcionan, descubrí que una versión anterior de la DLL que estaba incrustando estaba en el mismo directorio en el que estaba ejecutando mi .exe recién compilado de. Aparentemente, primero busca un archivo local en el mismo directorio, luego mira hacia adentro a su biblioteca incrustada. Eliminar la vieja DLL funcionó.

Para ser claros, no era que mi referencia apuntara a una DLL antigua, era que una copia de una DLL antigua estaba en el directorio desde el que estaba probando mi aplicación en un sistema separado del que se compiló.


1

En mi caso, era una carpeta con archivos DLL más antiguos del mismo nombre que aquellos a los que se hizo referencia en mi archivo .csproj, aunque la ruta se proporcionó explícitamente, de alguna manera se incluyeron, por lo tanto, las varias versiones de los mismos archivos DLL estaban en conflicto.



1

En mi caso, ¡MissingMethodException fue para un método que estaba en el mismo archivo!

Sin embargo, acababa de agregar un paquete NuGet que usa .Net Standard2 a mi proyecto de orientación 4.7.1, lo que causó un conflicto de versiones para System.Net.Http (4.7.1: versión 4.0.0.0, el paquete NuGet que usa .NET El estándar 2 quiere 4.2.0.0). Esto parece ser problemas conocidos que deberían ser mejores en 4.7.2 (ver nota 2) .

Había utilizado una redirección de enlace como esta en todos mis otros proyectos, porque hubo excepciones tan pronto como intentó cargar el 4.2.0.0 que no tenía:

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

Excepto en este proyecto, donde parece que intenta cargar System.Net.Http solo mientras llama a una función local que usa un System.Net.Http.HttpResponseMessage como parámetro o tipo de retorno (parámetro durante la depuración, tipo de retorno cuando ejecuto las pruebas sin el depurador, también un poco extraño). Y en lugar de mostrar un mensaje de que no pudo cargar la versión 4.2.0.0 de System.Net.Http, devuelve esta excepción.


0

Esto me sucedió usando MVC4, y decidí después de leer este hilo cambiar el nombre del objeto que arrojaba el error.

Hice una limpieza y reconstrucción y noté que estaba omitiendo dos proyectos. Cuando reconstruí uno de ellos, hubo un error en el que comencé una función y no la terminé.

Entonces VS estaba haciendo referencia a un modelo que había reescrito sin preguntarme si quería hacer eso.


0

En caso de que ayude a alguien, aunque es un problema antiguo, mi problema era un poco extraño.

Tuve este error al usar Jenkins.

Finalmente descubrí que la fecha del sistema se estableció manualmente en una fecha futura, lo que provocó que dll se compilara con esa fecha futura. Cuando la fecha se restableció a la normalidad, MSBuild interpretó que el archivo era más nuevo y no requería la recompilación del proyecto.


0

Me encontré con este problema, y ​​lo que fue para mí fue que un proyecto estaba usando una lista que estaba en el espacio de nombres Example.Sensors y otro tipo implementó la interfaz ISensorInfo. Clase Type1SensorInfo, pero esta clase era una capa más profunda en el espacio de nombres en Example.Sensors.Type1. Al intentar deserializar Type1SensorInfo en la lista, arrojó la excepción. Cuando agregué usando Example.Sensors.Type1 en la interfaz ISensorInfo, ¡no más excepciones!

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

Sucedió lo mismo cuando tuve una serie de procesos de MSBuild ejecutándose en segundo plano que efectivamente se bloquearon (tenían referencias a versiones antiguas de código). Cerré VS y eliminé todos los procesos de MSBuild en el explorador de procesos y luego los volví a compilar.


0

Tuve un proyecto de prueba que hace referencia a otros 2 proyectos que hacen referencia a diferentes versiones (en diferentes ubicaciones) del mismo dll. Esto confundió al compilador.


0

En mi caso, spotify.exe estaba usando el mismo puerto que mi proyecto de API web quería usar en una máquina de desarrollo. El número de puerto era 4381.

Dejé Spotify y todo volvió a funcionar bien :)


0

Tuve este problema cuando el método requería un parámetro que no estaba especificando


0

En mi caso, no hubo ningún cambio de código y de repente uno de los servidores comenzó a recibir esta y solo esta excepción (todos los servidores tienen el mismo código, pero solo uno comenzó a tener problemas):

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

Apilar:

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)

El problema creo que fue AppPool corrupto: hemos reciclado AppPool automatizado todos los días a las 3 a.m. y el problema comenzó a las 3 a.m. y luego terminó por sí solo a las 3 a.m. al día siguiente.


0

Debe ser un error de referencia de Microsoft.

Limpié, reconstruí en todas mis bibliotecas y aún tengo el mismo problema y no pude resolver esto.

Todo lo que hice fue cerrar la aplicación Visual Studio y volver a abrirla. Eso hizo el truco.

Es muy frustrante que un problema tan simple pueda tardar tanto tiempo en solucionarse porque no pensarías que será algo así.


0

En mi caso, mi proyecto estaba haciendo referencia Microsoft.Net.Compilers.2.10.0. Cuando lo cambié a Microsoft.Net.Compilers.2.7.0, el error desapareció. Qué error tan misterioso con tanta variedad de causas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.