¿La actualización de la aplicación con un nuevo .net dll me da FileLoadException?

Question

Tengo una aplicación .net 3.5 con muchos archivos DLL, intenté reconstruir un dll específico sin compilar toda la aplicación, pero después de reemplazar el anterior por el nuevo, la aplicación lanza una excepción ya que no pudo cargar la nueva excepción dll : System.IO.FileLoadException: No se pudo cargar el archivo o el ensamblado .... Entiendo que busca el ensamblado con una versión específica y token público, ¿cómo puedo solucionar este problema sin volver a compilar la aplicación? también la aplicación está firmada pero no registrada en GAC. P.S: ¿Cómo puedo omitir la construcción de la aplicación nuevamente, o es imprescindible cuando se reconstruye el dll?

Answer 1

La razón por la que recibe el error es porque su ensamblado está firmado, y lo más probable es que su referencia tenga la propiedad Versión específica establecida en Verdadero, y su número de versión del ensamblado al que hizo el cambio haya cambiado. Probé muchos escenarios, y este fue el único escenario en el que pude obtener la excepción FileLoadException. Si hubiera cambiado el Marco de destino a una versión más nueva como 4.0, en su lugar obtendría una BadImageFormatException. Incluso si dice que no cambió el número de versión, verifíquelo de todos modos, o configure la Versión específica como False seleccionando su referencia, y haciendo clic con el botón derecho y seleccionando propiedades.

Su probable excepción era la siguiente:

Could not load file or assembly 'LoadedAssembly, Version=1.0.0.0, Culture=neutral, 
PublicKeyToken=889080b75eb3bad2' or one of its dependencies. The located assembly's manifest 
definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) 

Sin embargo, su versión compilada si el ensamblado que se está haciendo referencia ya no es 1.0.0.0 (o cualquiera de sus versiones, por ejemplo). En la imagen siguiente (aunque pequeña), puede ver que la propiedad de referencia busca la versión 1.0.0.0, la Versión específica está establecida en Verdadero y el ensamblaje de referencia está firmado y es realmente la versión 2.0.0.0, lo que da como resultado la excepción FileLoadException.

Resuelva esto cambiando el número de versión y recompilando, o configurando la Versión específica como False y reconstruyendo solo esa DLL. No tiene que reconstruir toda su aplicación.

Answer 2

Debe reconstruir los ensamblados que hacen referencia a esta nueva dll.

Answer 3

El Windows EventLog debe proporcionar más información sobre lo que no se pudo cargar. ¿Introdujo otra dependencia en la nueva DLL? Me encontré con algo similar, donde una DLL de terceros requería que se instalara C++ Runtime 2005 (que es el caso en la mayoría de las máquinas Dev y también en la mayoría de las computadoras de escritorio, ya que es muy común).

Answer 4

Wild guess ... puede verificar si la carpeta donde vive la DLL está marcada como ReadOnly.

Haga clic con el botón derecho en la carpeta> Propiedades>desmarque ReadOnly> haga clic en Aplicar> elija todas las subcarpetas y archivos> Aceptar.

Reconstruya su solución.

Answer 5

¿Intentó hacer uso de DEVPATH variable de entorno? Esta variable de entorno le permite definir un directorio para que actúe como "GAC durante el desarrollo". Todo lo que tiene que hacer es:

1) Añadir el siguiente elemento a su machine.config (comprobación doble de lo que la ubicación de su machine.config se va a utilizar)

• C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG O

• C: \ Windows \ \ Framework \ v2.0.50727 \ Microsoft.NET CONFIG *

2) Agregar una nueva variable de entorno con el nombre DEVPATH

set devpath="e:\temp\Message_DLL\bin\Debug"  /// manually, console 
/// or open windows config form - see below 

3) Luego ir a la interfaz de usuario de aplicaciones/Proyecto y agregue una referencia a la DLL en el directorio DEVPATH.

Asegúrese de que ha configurado "copia local = false, versión específica = false". Como puede ver Nombre fuerte (nombre Starker) es verdadero.

4) ¡Ahora tiene que compilar su aplicación UI UNA VEZ! Después de eso, puede optar por cambiar su fuente en su DLL como lo desee. Debido a la variable DEVPATH, su aplicación de interfaz de usuario siempre elegirá la última versión de su DLL.

NOTA! He intentado iniciar la aplicación de interfaz de usuario desde VS pero he fallado con la excepción de carga. PERO comenzando desde las ventanas del explorador - tenido éxito. Parece que al iniciar la aplicación de interfaz de usuario de VS provoca que CLR busque en otra parte la DLL referida.

---

También puede echar un vistazo a MSDN y MSDN2.

Observaciones: Utilice esta configuración solo en el momento del desarrollo. El tiempo de ejecución no comprueba las versiones en conjuntos de nombre seguro que se encuentran en DEVPATH. Simplemente usa el primer ensamblaje que encuentra.

Puedes echar un vistazo a los siguientes artículos/páginas web, también.

CodeProject - Assembly location, binding, deploying

Social MSDN Questions about DEVPATH

creo que esto debería hacer el truco!