c# - varias - Método no encontrado en tiempo de ejecución
mostrar varias imagenes en un picturebox c# (18)
Tengo un proyecto ASP.Net c # tratando de acceder a métodos en una clase en otro proyecto. Está funcionando para la primera mitad de los métodos en la clase pero no para la otra mitad de los métodos en la clase que agregué recientemente. Se compilan, pero lanzan un método que no se encuentra excepción en tiempo de ejecución.
¿Alguien tiene alguna idea que pueda probar? He intentado:
- recreando el archivo
.sln - Subestado en otro proyecto de biblioteca de clase, que sé que funciona. Parece que el error está en mi proyecto principal que llama al método en el otro proyecto.
"Método no encontrado" es un error muy específico, lo que significa que un método que esperaba (es decir, estuvo allí en tiempo de compilación) simplemente no está presente. Por lo general, esto significa que los archivos que está implementando son diferentes de lo que cree que son, específicamente, apostaría a que está implementando la versión anterior de la biblioteca (que carece de sus adiciones).
Verifique los dlls implementados en el servidor web contra lo que cree que deberían ser.
Dos proyectos en su solución: el proyecto A y el proyecto B. Ambos proyectos usan el paquete nuget "DoStuff", pero diferentes versiones del paquete DoStuff:
- El proyecto A hace referencia a la versión 1.1 de DoStuff.
- El proyecto B hace referencia a la versión 1.0 de DoStuff.
- proyecto B referencias proyecto A.
la versión 1.1 tiene un nuevo método, que se usa en el proyecto A. cuando el proyecto B usa el proyecto A, obtendrá esta excepción MethodNotFoundException, porque la versión de DoStuff del proyecto B no sabe de qué se está hablando el proyecto A.
Para evitar esto, tenemos una prueba unitaria que falla si los proyectos utilizan versiones diferentes del mismo paquete de nuget. Un tope de puerta relativamente simple que nos ha ahorrado un par de dolores de cabeza en los últimos años.
El error también ocurrió cuando tuve una acción como parámetro. Pasé un método sin envolverlo en una nueva Acción (..).
DLL tenía esto:
public bool ShowMyForm(bool showConnectionWindow, Action onCloseNotify) {...}
Aplicación de prueba llamada la DLL como así:
private void onFormClose()
{
MessageBox.Show("Form Closed");
}
private void ShowForm()
{
mydll.ShowMyForm(true, onFormClose ); // bug here: wrap in Action
}
Cuando cambié la llamada a
mydll.ShowMyForm(true, new Action(onFormClose) );
La excepción desapareció. El texto de la excepción es simplemente engañoso: el método está ahí, pero el tipo de parámetro dio una excepción de tiempo de ejecución. Lástima que no se recoja en tiempo de compilación, sin embargo.
En mi caso, había cambiado el tipo de retorno de un método de IQueryable a IEnumerable.
Recopilé y subí la DLL que contiene el método pero no la DLL con el código que llama al método. De modo que la DLL de llamada aún esperaba el método con el tipo de retorno anterior y no pudo encontrarlo.
En mi caso, lo implementé en una PC .NET 3.0 (Windows XP) mientras que el objetivo de compilación fue .NET 3.5. Realmente me pregunto por qué no hay una advertencia más básica ...
El problema ha sido el uso de DataContract de System.Runtime.Serialisation.
Encontré el mismo problema cuando ejecutaba una aplicación con dlls administrados por paquetes nuget. Resulta que cuando trato de actualizar los dlls desde el gestor de paquetes nuget, no actualicé mi capa de prueba. Te sugiero que compruebes la versión de dlls a la que te refieres. Vaya a ObjectBrower en VS y verifique las dlls y verifique la ubicación de referencia: asegúrese de consultar las últimas dlls.
He enfrentado este tipo de problema pero he podido resolverlo. Vacié mi bin y carpeta de depuración e intenté construir el proyecto de nuevo. Funcionó, al menos para mí. O intenta limpiar la solución e intenta reconstruirla. Pero, por supuesto, publicar una parte de su código podría ser más útil.
Me enfrenté al mismo problema, incluso limpié y reconstruí la solución que no me ayudó. cuando publiqué la aplicación, la versión anterior de dll estaba en la carpeta bin. Así que cambié la versión de ensamblaje en el archivo assemblyinfo. finalmente está funcionando. La nueva versión está disponible en la carpeta bin.
Mi caso fue una pequeña variación de los otros aquí; pero podría ayudar a alguien. Acabo de agregar un argumento opcional en una biblioteca y recibí ese mensaje de la GUI usando la biblioteca.
El problema se debió a que la GUI y una de sus bibliotecas hacían referencia a la misma biblioteca pero una no estaba actualizada.
yo tengo
- GUI que hace referencia a LibA y LibZ
- LibA haciendo referencia a LibZ
Así que simplemente eliminé todas las carpetas "bin" y "obj" de LibA y GUI, me aseguré de tener la DLL actualizada de LibZ en ambas, y todo funcionó de nuevo.
Mire, esta debe ser la causa más rara, pero después de toda una mañana probando todo, reconstruyendo el proyecto desde cero, noté que lo único que evitaría el problema era que mi biblioteca tuviera un nombre de ensamblaje diferente.
Desde el fondo de mi mente, tuve una horrible sugerencia de que había instalado versiones anteriores de dll en el GAC, pero ya lo había comprobado y, además, nunca fue mi intención. Pero siguiendo ese rastro, descubrí que esta DLL (¡y todas las demás del proyecto!) Estaban instaladas en C: / Archivos de programa (x86) / Microsoft Visual Studio 10.0 / Common7 / IDE !!!!!!
¡Aaaargh! Supongo que soy el único que de alguna manera arruinó esto, pero no tengo ni idea de por qué, ¡solo pensé que podría ahorrarle a otra persona esta frustación en la remota posibilidad de que alguien sea tan desafortunado!
No pude arreglarlo con ninguna de las respuestas sugeridas. No pude encontrar ninguna versión antigua del ensamblaje personalizado. Literalmente busqué por todas partes con la herramienta Todo. En el modo de depuración, mostró la versión correcta del ensamblaje, pero aún no pudo encontrar el método.
Habilitar el enlace automático en el archivo .csproj solucionó para mí
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Estaba apuntando a un paquete de .NET Framework 4.5 en mi proyecto. La configuración anterior no es necesaria si todos los paquetes en el proyecto apuntan a .NET Framework 4.5.1 o superior.
Puede ser una respuesta tardía: pero un remedio posible es limpiar la carpeta de archivos temporales de ASP.NET: Es decir, C: / Windows / Microsoft.NET / Framework / vX.X.XXXXX / Archivos temporales de ASP.NET
Borre las carpetas relacionadas con su sitio web y reconstruya la solución.
También encontré esta misma excepción, aunque mi problema era diferente, tenía un método en una de mis bibliotecas que originalmente tenía este aspecto:
public void WriteMessage(string msg)
{
...
}
y hubo una nueva solicitud de modificación y se convirtió en esto:
public void WriteMessage(string msg, int code = 100)
{
...
}
después de eso, actualicé el proyecto que está utilizando esta biblioteca con un binario recién compilado, comenzó a lanzar esta excepción.
Después de muchos intentos, nada funcionó, incluso el proyecto se limpió, se reconstruyó, se eliminó y se volvió a agregar la referencia, luego intenté modificar la llamada al método del proyecto desde:
...
library.WriteMessage(''hello!'');
...
a:
...
library.WriteMessage(''hello!'', 100);
...
y luego compilé el proyecto, resolví el problema, después de eso lo cambié de nuevo a:
...
library.WriteMessage(''hello!'');
...
y ahora lo arregló todo de forma mágica, tal vez había algún tipo de metadatos almacenados en caché que no se estaban actualizando, y al cambiar la forma en que se llama al método, recuérdele claramente que la firma del método es diferente, pero no tan diferente.
Espero que esto pueda ayudar a alguien que enfrenta el mismo problema que yo experimenté.
Tuve el mismo problema, luego cambié el nombre del método a un nombre diferente y cambié las referencias. entonces funciona muy bien. No sé cuál fue el problema, pero parece que hay un error al cambiar el nombre de un método en algunas circunstancias que no se aplica a todo el sistema
Tuve el mismo problema. En mi caso, fue causado por la adición de un argumento opcional . Así que primero tendrías:
montaje de referencia
referencedAssembly.DoStuff(firstArgument, secondArgument)
Ensamblaje referenciado:
public void DoStuff(string firstArgument, string secondArgument)
{
//stuff to do
}
Luego agrega un parámetro opcional al método, pero no proporciona ese argumento mientras lo llama.
montaje de referencia
referencedAssembly.DoStuff(firstArgument, secondArgument)//unchanged
Ensamblaje referenciado:
public void DoStuff(string firstArgument, string secondArgument, string thirdArgument = "default value")
{
//stuff to do
}
A nivel local, esto generará y funcionará correctamente, ya que la nueva creación de referencingAssembly.dll tendrá una referencia al método DoStuff (cadena, cadena, cadena). Pero cuando solo implementas el conjunto de referencia modificado (pensando: el argumento agregado era opcional, y el conjunto de referencia aún funciona), la versión anterior de referenciaer ensambla lanzará un MethodNotFound ya que busca un método con la firma DoStuff (cadena, cadena), que es ya no está presente en el referencedAssembly ya que agregamos el argumento extra (opcional).
Una posible solución podría ser una sobrecarga:
Ensamblaje referenciado:
public void DoStuff(string firstArgument, string secondArgument)//original method
{
DoStuff(firstArgument, secondArgument, "default value")
}
public void DoStuff(string firstArgument, string secondArgument, string thirdArgument)//new overload of the method
{
//stuff to do
}
O implementando el nuevo ensamblado de referencia (que se referirá al método con la firma DoStuff (cadena, cadena, cadena)).
Tuve este problema cuando había copiado la solución a una ubicación diferente en otra máquina. La carpeta Build solo necesitaba ser cambiada. No me preguntes por qué, pero la solución se creó en la carpeta de compilación (llamaremos a esta carpeta A), luego se copió una copia antigua de la carpeta B a la carpeta C. En el tiempo de ejecución no pudo encontrar mi último código porque era buscando una versión anterior en la carpeta C. En Propiedades de la solución en la pestaña Generar, cambié la Ruta de salida a la carpeta B. Luego construyó la última versión en la carpeta B que copió en la carpeta C y todo volvió a funcionar.
Lo que no sé es por qué tenemos la carpeta C en primer lugar. Tengo una solución de prueba de UDI codificada y la carpeta C es "C: / Users // Documents / MyCodedUISolution / TestResults / _ 2017-04-20 11_31_29 / Out". Para qué se usa y por qué se creó, no lo sé, pero si aquí se copia el código antiguo porque cambia la Ruta de salida o si mueve la solución sin cambiar la Ruta de salida a lo que se necesita, entonces tiene problemas.
Tuve un problema muy similar y descubrí que se había instalado una versión anterior del ensamblaje en el GAC. Después de que desinstalé esa versión, el proyecto se compiló y se ejecutó correctamente. Así que verifique el GAC ( C:/Windows/Assembly ) para asegurarse de que no esté en la lista.
Tuvo el mismo problema, en mi caso, la configuración de las Compilaciones optimizadas en falso en el webconfig resolvió el problema.