"Se intentó cargar un programa con un formato incorrecto" incluso cuando las plataformas son las mismas

Llamo funciones desde una DLL no administrada de 32 bits en un sistema de 64 bits. Lo que obtengo es:

BadImageFormatException: se intentó cargar un programa con un formato incorrecto. (Excepción de HRESULT: 0x8007000B)

Al principio, tenía mis proyectos configurados en la plataforma Any CPU, así que los cambié a ambos a x86, pero este error sigue ocurriendo. Esa es realmente la única solución que sé para esto.

Las DLL no están dañadas ni nada, porque puedo usarlas con otros programas (para los que no tengo la fuente). Pensé que tal vez no estaba encontrando una dependencia, pero lo comprobé y todos están allí. Además, ¿no arrojaría un DllNotFoundExceptionen ese caso?

¿Que más puedo hacer? Y antes de decir "Use una DLL no administrada de 64 bits en su lugar", permítame señalar que no hay una. ;)

Si intenta ejecutar aplicaciones de 32 bits en IIS 7 (y / o en una máquina con sistema operativo de 64 bits), obtendrá el mismo error. Entonces, desde IIS 7, haga clic derecho en el grupo de aplicaciones de las aplicaciones y vaya a "configuración avanzada" y cambie "Habilitar aplicaciones de 32 bits" a "VERDADERO".

Reinicie su sitio web y debería funcionar.

De alguna manera, la casilla de verificación Construir en el Administrador de configuración había sido desmarcada para mi ejecutable, por lo que todavía se estaba ejecutando con la antigua versión Any CPU. Después de arreglar eso, Visual Studio se quejó de que no podía depurar el ensamblaje, pero eso se solucionó con un reinicio.

En Visual Studio , haga clic con el botón derecho en su proyecto -> En el panel izquierdo, haga clic en la pestaña Generar ,

en Destino de plataforma, seleccione x86 (o más generalmente, la arquitectura para que coincida con la biblioteca a la que se está vinculando)

¡Espero que esto ayude a alguien! :)

Acabo de tener este problema también. Intenté todas las sugerencias aquí, pero no ayudaron.

Encontré otra cosa para verificar que me lo arregló. En Visual Studio, haga clic derecho en el proyecto y abra "Propiedades". Haga clic en la pestaña "Compilar" (o "Compilar") y luego haga clic en "Opciones de compilación avanzadas" en la parte inferior.

Verifique el menú desplegable "CPU objetivo". Debe coincidir con la "Plataforma" que está construyendo. Es decir, si está construyendo "Cualquier CPU", entonces "CPU de destino" debería decir "Cualquier CPU". Revisa todas tus plataformas activándolas y verifica esta configuración.

Si encuentra este error cuando hace clic en el botón de flecha verde para ejecutar la aplicación, pero aún así desea ejecutar la aplicación en 64 bits. Puede hacer esto en VS 2013, 2015, 2017 y 2019

Vaya a: Herramientas> Opciones> Proyectos y soluciones> Proyectos web> Use la versión de 64 bits de IIS Express

Si está utilizando Any CPU , puede encontrar este problema si la opción Preferir de 32 bits está marcada:

¡Asegúrese de desmarcar esta opción en la pestaña Construir de la propiedad del proyecto !

Un poco fuera de tema para esta publicación, pero la búsqueda de este mensaje de error me trajo aquí.

Si está compilando a través del sistema de equipo y obtiene este error, la pestaña del proceso de definición de compilación tiene una configuración de "Plataforma MSBuild". Si está configurado en "Auto", puede experimentar este problema. Cambiarlo a "X86" también puede resolver el error.

En mi caso, estaba usando una DLL nativa en C #. Esta DLL dependía de algunas otras DLL que faltaban. Una vez que se agregaron esas otras DLL, todo funcionó.

Sobre la base de la respuesta de @paibamboo

Él dijo: Vaya a: Herramientas> Opciones> Proyectos y soluciones> Proyectos web> Use la versión de 64 bits de IIS Express

Mi compañero de trabajo tenía esta casilla marcada (lo buscó explícitamente), pero tenía el mensaje de error en cuestión. Después de algunas horas, desmarcó la casilla y la volvió a marcar. Lo y he aquí: el código ahora se ejecutó con éxito.

Parece que hay dos lugares donde se guarda el estado de este cuadro que no está sincronizado. Descomprimirlo y volver a verificarlo lo sincronizó nuevamente.

Pregunta para usuarios más conocedores: ¿Hubo una actualización o algo la semana pasada (para VS 2015) que desincronizó los estados?

También vea esta respuesta , que resolvió el mismo problema para mí.

Publicado por Luis Mack el 12/05/2010 a las 8:50 AM. He encontrado el mismo problema, solo para un proyecto específico al compilar en una máquina de 64 bits. Una solución que PARECE funcionar es alterar manualmente un carácter en la secuencia de imágenes CADA VEZ que el control del usuario o el formulario se editan en el diseñador

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w

Cambiar a

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w

Eso es 00LjAuMC4w de regreso a 0yLjAuMC4w al final de la línea (00 de regreso a 0y)

En mi caso, estoy usando un pequeño .exe que vuelve a cargar las DLL a las que se hace referencia a través de Reflection. Así que solo hago estos pasos que me salvan el día:

Desde las propiedades del proyecto en el explorador de soluciones, en la pestaña de compilación, elijo la plataforma objetivo desde x86

En mi caso, estaba ejecutando pruebas a través de MSTest y descubrí que estaba implementando una DLL de 32 bits y de 64 bits en el directorio de prueba. El programa favorecía la DLL de 64 bits y hacía que fallara.

TL; DR Asegúrese de implementar solo DLL de 32 bits para las pruebas.

Tuvimos un problema similar y logramos solucionarlo estableciendo el objetivo de la Plataforma en x86.

Tengo este problema resuelto en la forma de 'Windows'. Después de verificar todas mis configuraciones, limpiar la solución y reconstruirla, simplemente cierro la solución y la vuelvo a abrir. Luego funcionó, por lo que VS probablemente no se deshizo de algunas cosas durante la limpieza. Cuando las soluciones lógicas no funcionan, suelo recurrir a soluciones ilógicas (o aparentemente ilógicas). Windows no me decepciona. :)

Pude solucionar este problema haciendo coincidir mi versión de compilación con la versión .NET del servidor.

Hice doble clic en el .exe solo para ver qué sucedería y me dijo que instalara 4.5 ...

¡Así que bajé a 4.0 y funcionó!

Así que asegúrese de que sus versiones coincidan. Funcionó bien en mi cuadro de desarrollo, pero el servidor tenía una versión anterior de .NET.

En mi caso, el contenido del archivo era incorrecto. La DLL se descargó de la web, pero el contenido de la DLL era una página HTML: D Intente verificar si es un archivo binario, si parece que la DLL es correcta :)

Estábamos teniendo el mismo problema en .NET core. La solución fue descargar .netcore runtime de 32 bits y tener el objetivo de su proyectox86

En su csprojarchivo agregue

  <PropertyGroup>
    <PlatformTarget>x86</PlatformTarget>  
  </PropertyGroup>

  <PropertyGroup>
    <RunCommand Condition="'$(PlatformTarget)' == 'x86'">$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>    
  </PropertyGroup>

Esto se usó para una máquina Windows, tendrías que ajustar las rutas y tal para Linux / OSX

Si está importando una DLL no administrada, use

CallingConvention = CallingConvention.Cdecl 

en su método de importación de DLL.

1: Vaya a: Herramientas> Opciones> Proyectos y soluciones> Proyectos web> Use la versión de 64 bits de IIS Express 2: cambie la configuración a continuación para el proyecto de servicio web.