Solución de problemas de BadImageFormatException

Tengo un servicio de Windows escrito en C # utilizando Visual Studio 2010 y apuntando a .NET Framework 4. Cuando ejecuto desde una comstackción de depuración el servicio se ejecuta como se esperaba. Sin embargo, cuando lo ejecuto desde una versión de Release obtengo una System.BadImageFormatException (detalles a continuación). He estado buscando una solución en Internet, pero hasta ahora todo lo que he encontrado no me ha ayudado a encontrar una solución.

El problema existe en los sistemas de Windows 7 de 64 bits (dev) y Windows XP SP3 de 32 bits (de destino).

Esto es lo que he intentado hasta ahora:

  • Las configuraciones de comstackción verificadas, como el objective de la plataforma, son todas iguales (x86).
  • Se usó peverify con la opción / verbose para garantizar que los archivos binarios de ensamblaje fueran válidos.
  • Utiliza fuslogvw para buscar cualquier problema de carga.
  • Se utiliza CheckAsm para buscar archivos o conjuntos faltantes.

Todos estos controles no cambiaron nada. He incluido el texto completo de la información de excepción a continuación, con algunos de los nombres modificados para proteger los secretos de mis maestros corporativos.

 System.BadImageFormatException no se ha manejado Mensaje = No se pudo cargar el archivo o ensamblado 'XxxDevices, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' o una de sus dependencias.  Se intentó cargar un progtwig con un formato incorrecto.  Fuente = XxxDevicesService FileName = XxxDevices, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null FusionLog = Administrador de ensamblados cargado desde: C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ clr.dll Ejecutando bajo el ejecutable c: \ Dev \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe --- A continuación, aparece un registro de error detallado.  === Información de estado de enlace previo === REGISTRO: Usuario = XXX REGISTRO: DisplayName = XxxDevices, Versión = 1.0.0.0, Cultura = neutral, PublicKeyToken = null (Completamente especificado) LOG: Appbase = archivo: /// c : / Dev / TeamE / bin / Release / LOG: Initial PrivatePath = NULL Conjunto de llamada: XxxDevicesService, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null.  === LOG: Este enlace se inicia en el contexto de carga predeterminado.  LOG: Usando el archivo de configuración de la aplicación: c: \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe.Config LOG: Usando el archivo de configuración del host: LOG: Usando el archivo de configuración de la máquina desde C: \ Windows \ Microsoft.NET \ Framework64 \ v4. 0.30319 \ config \ machine.config.  LOG: Política que no se aplica a la referencia en este momento (enlace de ensamblaje privado, personalizado, parcial o basado en la ubicación).  LOG: Intentando descargar el nuevo archivo URL: /// c: /TeamE/bin/Release/XxxDevices.DLL.  ERR: Error al completar la configuración del ensamblado (hr = 0x8007000b).  Sonda terminada.  StackTrace: en XxxDevicesService.Program.Main (String [] args) en System.AppDomain._nExecuteAssembly (ensamblado RuntimeAssembly, String [] args) en Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly () en System.Threading.ExecutionContext.Run ( ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx) en System.Threading.ExecutionContext.Run (ExecutionContext executionContext, ContextCallback callback, Object state) en System.Threading.ThreadHelper.ThreadStart () InnerException: 

Las configuraciones de comstackción verificadas, como el objective de la plataforma, son todas iguales (x86).

Eso no es lo que dice el registro de fallos:

Administrador de ensamblaje cargado desde: C: \ Windows \ Microsoft.NET \ Framework64

Tenga en cuenta el 64 en el nombre, ese es el hogar de la versión de 64 bits del marco. Establezca la configuración de la plataforma de destino en su proyecto EXE , no su proyecto de biblioteca de clase. El proyecto EXE de XxxDevicesService determina la bitidez del proceso.

Después de dejar de golpear mi cabeza en el escritorio pensando en toda la semana que pasé corriendo este problema, estoy compartiendo lo que funcionó para mí. Tengo Win7 64 bit, Oracle Client de 32 bits y tengo mi proyecto MVC 5 configurado para ejecutarse en la plataforma x86 debido a la bitness de Oracle. Seguí recibiendo los mismos errores:

No se pudo cargar el archivo o ensamblado ‘Oracle.DataAccess’ o una de sus dependencias. Se intentó cargar un progtwig con un formato incorrecto.

Recargué los paquetes NuGet, utilicé copias de las DLL que funcionaban para otros en diferentes aplicaciones, configuré la base de código en el ensamblado dependiente para apuntar a la carpeta bin de mi proyecto, probé CopyLocal como verdadero o falso, lo intenté todo. Finalmente, hice lo suficiente. Quería verificar mi código y, como nuevo contratista, no tenía configuración de subversión. Mientras buscaba la manera de conectarlo a VS, tropecé con la respuesta. Lo que encontré funcionó fue desmarcar la opción “Usar la versión de 64 bits de IIS Express para sitios web y proyectos” en la sección Proyectos y soluciones => Proyectos web en el menú Herramientas => Opciones.

Lo que encontré fue comprobar la opción “Usar la versión de 64 bits de IIS Express para sitios web y proyectos” en la sección Proyectos y soluciones => Proyectos web en el menú Herramientas => Opciones.

Normalmente puede ocurrir cuando cambiaste el marco de destino de .csproj y lo volviste a lo que comenzaste.

Asegúrese de 1 si supportedRuntime version = “un tiempo de ejecución diferente del objective del proyecto cs” debajo de la etiqueta de inicio en app.config.

Asegúrese de que 2 también significa verificar otros archivos autogenerados u otros archivos en la carpeta de propiedades para ver si no hay más desajuste en el tiempo de ejecución entre estos archivos y uno que está definido en el archivo .csproj.

Esto podría ahorrarle mucho tiempo antes de comenzar a probar diferentes cosas con las propiedades del proyecto para superar el error.

Tuve el mismo problema aunque tengo Windows 7 de 64 bits y estaba cargando un b / c de DLL de 64 bits en las propiedades del proyecto | Build: he marcado “Prefer 32-bit”. (No sé por qué está configurado por defecto). Una vez que desmarqué eso, todo salió bien

También puede obtener esta excepción cuando su aplicación se dirige a .NET Framework 4.5 (por ejemplo) y tiene la siguiente app.config:

        

Al intentar iniciar la depuración de la aplicación obtendrá la BadImageFormatException.

Al eliminar la línea que declara la versión v2.0 se borrará el error.

Tuve este problema recientemente cuando traté de cambiar la plataforma de destino de un antiguo proyecto .NET 2.0 a .NET 4.5.

Fondo

Empezamos a recibir esto hoy cuando cambiamos nuestro servicio WCF de AnyCPU a x64 en un servidor Windows 2012 R2 que ejecuta IIS 6.2.

Primero revisamos el único ensamblaje referenciado 10 veces, para asegurarnos de que no era realmente un dll x86. A continuación, verificamos el grupo de aplicaciones muchas veces para asegurarnos de que no estaba habilitando aplicaciones de 32 bits.

En un capricho intenté alternar la configuración. Resultó que los grupos de aplicaciones en IIS estaban predeterminados a un valor de Permitir aplicaciones de 32 bits de False, pero IIS lo ignoraba en nuestro servidor por alguna razón y siempre ejecutó nuestro servicio en modo x86.

Solución

  • Seleccione el grupo de aplicaciones.
  • Elija Establecer valores predeterminados del conjunto de aplicaciones … o Configuración avanzada ….
  • Cambie Activar aplicaciones de 32 bits a True.
  • Haga clic en Aceptar .
  • Elija Establecer valores predeterminados del conjunto de aplicaciones … o Configuración avanzada … de nuevo.
  • Cambie Activar aplicaciones de 32 bits a False.
  • Haga clic en Aceptar .

Solucioné este problema cambiando la aplicación web para usar un “grupo de aplicaciones” diferente.

Para cualquiera que llegue aquí más tarde … Nada funcionó para mí. Todas mis asambleas estaban bien. Tenía una configuración de aplicación en uno de mis proyectos de Visual Studio que no debería haber estado allí. Así que asegúrese de que el archivo de configuración de su aplicación sea necesario.

Eliminé la configuración extra de la aplicación y funcionó.

Determine el grupo de aplicaciones utilizado por la aplicación y establezca la propiedad de estableciendo Activar las aplicaciones de 32 bits en True. Esto puede hacerse a través de configuraciones avanzadas del grupo de aplicaciones.

Al crear aplicaciones para plataformas de 32 o 64 bits (Mi experiencia es con Visual Studio 2010), no confíe en Configuration Manager para establecer la plataforma correcta para el ejecutable. Incluso si el CM tiene x86 seleccionado para la aplicación, verifique las propiedades del proyecto (pestaña Construir): aún podría decir “Cualquier CPU” allí. Y si ejecuta un ejecutable “Any CPU” en una plataforma de 64 bits, se ejecutará en modo de 64 bits y se rehusará a cargar los archivos DLL que lo acompañan que fueron creados para la plataforma x86.

Para cualquiera que pueda llegar aquí más tarde …
Para la solución de escritorio obtuve la excepción BadImageFormatException .
Todas las opciones de comstackción del proyecto estaban bien (todas x86 ). Pero el proyecto de solución StartUp fue cambiado a algún otro proyecto (proyecto de biblioteca de clase).

Cambiar el proyecto de inicio al original (proyecto de aplicación .exe) fue una solución en mi caso

Cuando me enfrenté a este problema, lo siguiente lo resolví para mí:

Estaba llamando a un dll de OpenCV desde otro exe, mi dll no contenía los dlls de opencv ya necesarios, como highgui, features2d y etc., disponibles en la carpeta de mi archivo exe. Copié todo esto al directorio de mi proyecto exe y de repente funcionó.

Elimine su dependencia de System.Runtime en su Web.Config, funcionó para mí:

     

Este error “No se pudo cargar el archivo o ensamblado ‘ejemplo’ o una de sus dependencias. Se intentó cargar un progtwig con un formato incorrecto” generalmente es causado por una configuración incorrecta del grupo de aplicaciones.

  1. Asegúrese de que la AppPool en la que se está ejecutando su sitio tiene “Habilitar aplicaciones de 32 bits” establecido en False.
  2. Asegúrese de estar utilizando la versión correcta para su plataforma.
  3. Si obtiene este error en un sitio web, asegúrese de que su grupo de aplicaciones esté configurado para ejecutarse en el modo correcto (los sitios 3.0 deben ejecutarse en modo de 64 bits).
  4. También debe asegurarse de que la referencia a ese ensamblaje en Visual Studio apunte al archivo correcto en la carpeta de paquetes.
  5. Asegúrese de tener la versión correcta del dll instalado en el GAC para los sitios 2.0.
  6. Esto también puede ser causado por WSODLibs que se promocionan con el proyecto web.

Para .NET Core , existe un error de Visual Studio 2017 que puede causar que la página de creación de propiedades del proyecto muestre el objective de la plataforma incorrecta. Una vez que descubre que el problema es, las soluciones son bastante fáciles. Puede cambiar el objective a algún otro valor y luego cambiarlo de nuevo.

Alternativamente, puede agregar un identificador de tiempo de ejecución al .csproj. Si necesita que su .exe se ejecute como x86 para que pueda cargar una DLL nativa x86, agregue este elemento dentro de un PropertyGroup :

 win-x86 

Un buen lugar para poner esto es correcto después del elemento TargetFramework o TargetFrameworks .