c# - método - system.net.http.formatting nuget
System.MissingMethodException: ¿Método no encontrado? (23)
¡Revisa tus referencias!
Asegúrese de estar constantemente apuntando a las mismas bibliotecas de terceros (no solo confíe en las versiones, mire la ruta) en sus proyectos de soluciones.
Por ejemplo, si utiliza iTextSharp v.1.00.101 en un proyecto y NuGet o hace referencia a iTextSharp v1.00.102 en otro lugar, obtendrá estos tipos de errores de tiempo de ejecución que de alguna manera se filtran a su código.
Cambié mi referencia a iTextSharp en los 3 proyectos para apuntar a la misma DLL y todo funcionó.
Lo que antes funcionaba en mi aplicación asp.net webforms arroja ahora este error:
System.MissingMethodException: Método no encontrado
El método DoThis 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()
{
//
}
}
¿Has intentado encender y apagar nuevamente? Bromas aparte, reiniciar mi computadora fue lo que realmente funcionó para mí y no se menciona en ninguna de las otras respuestas.
Acabo de tener este problema y resultó que fue porque estaba haciendo referencia a una versión anterior de la DLL de mi proyecto de interfaz de usuario. Por lo tanto, al compilar, fue feliz. Pero cuando lo ejecutaba usaba la versión anterior de la DLL.
Compruebe las referencias en todos los demás proyectos antes de asumir que necesita reconstruir / limpiar / volver a implementar sus soluciones.
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.
Eventualmente descubrió que la fecha del sistema se estableció manualmente en una fecha futura, lo que provocó que se compilara dll con esa fecha futura. Cuando la fecha volvió a ser normal, MSBuild interpretó que el archivo era más nuevo y no requería la recompilación del proyecto.
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 delante del ctor)
que compiló perfectamente bien, pero cuando AutoMapper intenta crear una instancia del perfil no puede (¡por supuesto!) encontrar el constructor!
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.
Salí de Spotify y todo funcionó bien de nuevo :)
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ó ...
Este es un problema que puede ocurrir cuando hay una versión anterior de un archivo DLL que aún persiste. Asegúrese de que los ensamblados más recientes estén implementados y que no haya conjuntos antiguos duplicados escondidos en determinadas carpetas. Su mejor opción sería eliminar cada elemento construido y reconstruir / volver a implementar toda la solución.
Esto me sucedió usando MVC4, y después de leer este hilo decidí cambiar el nombre del objeto que arrojaba el error.
Hice una limpieza y reconstrucción y noté que se estaba salteando dos proyectos. Cuando reconstruí uno de ellos, hubo un error por el cual comencé una función y no la terminé.
Así que VS hacía referencia a un modelo que había reescrito sin preguntarme si quería hacerlo.
Me encontré con este problema, y lo que era para mí era que un proyecto usaba una lista que estaba en el espacio de nombres Ejemplo.Sensor y otro tipo implementaba 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é el uso de 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()
}
}
Me encontré con esto en un proyecto .NET MVC. La causa principal eran versiones conflictivas de 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 Enterprise Logistics Semantic Logging, 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 error misterioso de "Método no encontrado" cuando traté de usar el paquete.
La solución fue eliminar los paquetes antiguos NuGet de los dos proyectos, de modo que solo se incluyó en el proyecto que realmente lo necesitaba. (También hice una reconstrucción limpia de toda la solución).
Me sucedió esto con un archivo al que se hace referencia en el mismo ensamblaje, no a un dll separado. Una vez que excluí el archivo del proyecto y luego lo incluí de nuevo, todo funcionó bien.
Resolví este problema haciendo un conjunto de estanterías con mis cambios y ejecutando TFS Power Tools ''scorch'' en mi área de trabajo ( https://visualstudiogallery.msdn.microsoft.com/f017b10c-02b4-4d6d-9845-58a06545627f ). Luego desmantelé los cambios y recompuse el proyecto. De esta manera limpiarás cualquier ''fiesta colgante'' que pueda existir en tu área de trabajo y se iniciará con una nueva. Esto requiere, por supuesto, que esté usando TFS.
Resolví este problema instalando la versión correcta de .NET Framework en el servidor. El sitio web se estaba ejecutando con la versión 4.0 y el ensamblado al que estaba llamando se compiló para 4.5. Después de la instalación de .NET Framework 4.5 y la actualización del sitio web a 4.5, todo funciona bien.
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")]
También es posible que el problema sea con un parámetro o tipo de devolución del método que se ha informado que falta, y el método "perdido" per se 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 el 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 la versión utilizados. Al eliminar esa versión anterior / superior del GAC, se solucionó el problema.
Tuve la misma ocurrencia cuando tuve varios procesos de MSBuild ejecutándose en segundo plano que se habían bloqueado efectivamente (tenían referencias a versiones anteriores de código). Cerré VS y maté todos los procesos de MSBuild en el explorador de procesos y luego volví a compilar.
Tuve un proyecto de prueba que hace referencia a otros 2 proyectos que cada uno hace referencia a diferentes versiones (en diferentes ubicaciones) de la misma dll. Esto confundió al compilador.
Tuve una situación similar en la que recibía esta misma excepción. Tenía dos proyectos en mi solución de aplicación web, llamados, por ejemplo, DAL y DAL.CustSpec. El proyecto DAL tenía un método llamado Method1, 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 a Method1. El proyecto AnotherProj tenía una referencia al proyecto DAL.CustSpec, y no al proyecto DAL. La configuración de compilación tenía los proyectos DAL y DAL.CustSpec configurados para compilarse. 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 temporal ASP.NET 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 llamada Método1, recibí un error de "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, eliminé todos los archivos en la carpeta Archivos temporales ASP.NET y luego reintenté el sitio web. Después de eso, todo comenzó a funcionar. También me aseguré de que el proyecto DAL.CustSpec no se construyera desmarcando en la Configuración de compilación.
Pensé que podría compartir esto en caso de que ayude a alguien más en el futuro.
Usando Costura.Fody 1.6 y 2.0:
Después de perder un montón de tiempo investigando el 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 desde el que ejecutaba mi .exe recién compilado. Aparentemente, busca un archivo local en el mismo directorio primero, luego mira hacia adentro a su biblioteca incrustada. Eliminar la antigua DLL funcionó.
Para que quede claro, no era que mi referencia apuntaba a una antigua DLL, era que una copia de una antigua DLL estaba en el directorio donde estaba probando mi aplicación en un sistema separado del que estaba compilado.
reiniciar el estudio visual en realidad lo solucionó para mí. Estoy pensando que fue causado por viejos archivos de ensamblaje aún en uso, y que realizar una "compilación limpia" o reiniciar VS debería solucionarlo.
también ... ¡trate de "limpiar" sus proyectos o soluciones y reconstruir nuevamente!
Versión incorrecta del paquete de Nuget
Tenía un proyecto de prueba de unidad que estaba tirando de nuestro paquete de acceso a datos EF Nuget de nuestra compañía y esa versión estaba muy por detrás de la versión actual.
La configuración de Nuget para el paquete mencionado anteriormente usaba la least version para esos otros paquetes que eran los paquetes de segundo nivel dependientes.
Por lo tanto, obtuvo silenciosamente la versión incorrecta para una asamblea relacionada .
Solución
Al configurar / actualizar el paquete en Nuget para [obtener] el último problema solucionado.