No se pudo cargar el archivo o el ensamblado... Se intentó cargar un programa con un formato incorrecto (System.BadImageFormatException)

Estoy bastante seguro de que tiene un conflicto de 32 bits/64 bits. Parece que su proyecto principal podría estar configurado en 32 bits, mientras que la clase a la que hace referencia está configurada en 64 bits. Intenta mirar esta pregunta SO y este también. Entre los dos, deberías poder resolver tu problema.

Es posible que esté enfrentando el problema con su sitio web después de implementarlo en el servidor.

Entonces necesita ajustar su grupo de aplicaciones para Habilitar aplicaciones de 32 bits.

Proceso

1. Abra el administrador de IIS
2. Haga clic en Grupos de aplicaciones
3. Seleccione el grupo de aplicaciones que esté utilizando

4. En el panel derecho, haga clic en Configuración avanzada...

5. Establezca Habilitar aplicaciones de 32 bits en Verdadero

   

Acabo de recibir este mensaje de error al ejecutar IIS Express en Visual Studio 2015. En mi caso, necesitaba ejecutar la versión de 64 bits de IIS Express:

Herramientas → Opciones → Proyectos y Soluciones → Proyectos Web
Marque la casilla que dice "Usar la versión de 64 bits de IIS Express para sitios web y proyectos".

Captura de pantalla:

Yo tuve el mísmo problema. Configuré el "Objetivo de la plataforma" del Proyecto A ("Proyecto A" (clic con el botón derecho)->Propiedades->Crear->"Objetivo de la plataforma") en x86, pero mantuve el Proyecto B en "Cualquier CPU". La configuración del Proyecto B en "x86" solucionó esto.

Tuve este problema al ejecutar pruebas unitarias (xunit) en Visual Studio 2015 y encontré la siguiente solución:

Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64

Es posible que deba cambiar el Grupo de aplicaciones configurando "Habilitar aplicaciones de 32 bits" en VERDADERO en IIS7 si tiene al menos 1 dll\exe de 32 bits en su proyecto.

En primer lugar, obtuve esto en VS2017 con un proyecto antiguo que necesitaba para hacer un poquito cambiar y actualizar todos los proyectos al marco 4.7.

Varios otros han mencionado seleccionar Any CPU puede solucionar este problema.

Hay un par de lugares donde debe hacerlo, y puede que no sea tan simple como seleccionar del menú desplegable. Esto me lo arregló:

1) Tienes que hacerlo tanto aquí:

2) Y también en Configuration Manager (clic derecho en la solución)

Pero, ¿y si no está allí?

A continuación, haga clic en New y elige estos ajustes: (gracias @RckLN)

Lo siguiente resolvió el problema para mí, desmarque 'Preferir 32 bits':

Tuve el mismo problema con varios proyectos en la misma solución, terminé configurando todos los marcos de destino en .NET Framework 4 y x86 para la CPU de destino y finalmente se compiló correctamente.

Ninguna de estas soluciones funcionó para mí, pero al eliminar el contenido de las carpetas bin y obj, todo volvió a estar bien.

Obtuve esto cuando construí un proyecto a través de Visual Studio Online (VSTS) Build usando Visual Studio Build Pasos.

La solucion fue:

• Eliminar la carpeta de origen existente
• Establezca explícitamente "Cualquier CPU" en la plataforma para todas las compilaciones de Visual Studio, incluidas las dependencias (vea la captura de pantalla a continuación).
• Vuelva a ejecutar la compilación

El ensamblado Chilkat .NET 4.5 requiere que el tiempo de ejecución VC++ 2012 o 2013 esté instalado en cualquier computadora donde se ejecute su aplicación. La mayoría de las computadoras ya lo tendrán instalado. Su computadora de desarrollo lo tendrá porque se instaló Visual Studio. Sin embargo, si se implementa en una computadora donde el tiempo de ejecución de VC++ requerido no está disponible, se producirá el error anterior:

Instale todos los paquetes a continuación

Paquetes redistribuibles de Visual C++ para Visual Studio 2013 - vcredist_x64

Paquetes redistribuibles de Visual C++ para Visual Studio 2013 - vcredist_x86

Paquetes redistribuibles de Visual C++ para Visual Studio 2012 - vcredist_x64

Paquetes redistribuibles de Visual C++ para Visual Studio 2012 - vcredist_x86

También puede ver este problema si intenta empaquetar un proyecto de 64 bits con un instalador MSI en VS. ("El motivo es que el shim nativo empaquetado con el archivo .msi es un ejecutable de 32 bits").

Mira aquí para más detalles: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx

Para la versión más reciente de Visual Studio (v16.10 para esta respuesta), se puede solucionar cambiando manualmente la plataforma de la solución. Para mí funcionó después de cambiar de "Cualquier CPU" a "x86".

1. Haga clic en el menú desplegable de la plataforma de soluciones, en el que aparece cualquier CPU en la imagen a continuación.

2. Ir al administrador de configuración.

   

3. Haga clic en nuevo y agregue la plataforma x86 o x64 (32 o 64 bits) según lo que funcione para usted.

4. Reinicie el proyecto.

Yo también tuve este problema. Como mencioné antes el problema estaba relacionado con un conflicto de 32 bits/64 bits, pero con el sitio alojado en Azure. Para cambiar la plataforma en Azure App Service, vaya a Configuración -> Configuración general.

Encontré el mismo problema. Apareció de la nada y eso me pareció extraño.

En la instantánea de excepción, para FusionLog, vi lo siguiente dentro de su mensaje:

... C:\Windows\Microsoft.NET\Framework64...

Más sobre el registro de fusión: http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx

Todos los proyectos tenían una CPU de destino de AnyCPU. Cambié el proyecto de la aplicación (el proyecto que hace referencia a todos los demás proyectos) a una CPU de destino de x86. Ahora funciona.

No estoy seguro de cómo se produjo la confusión de la CPU de destino sin motivo aparente, pero así fue.

También enfrenté este problema en un proyecto, después de unos minutos encontré la solución, este problema se debe a la configuración de la CPU, si está usando Visual Studio 2010 o VS 2013, solo ve al proyecto de propiedades Y luego seleccione Compilar desde la barra lateral y habrá 5 menús desplegables, el quinto menú desplegable será CPU de destino:, deberías configurarlo en x86 o x64 de acuerdo con sus requisitos en lugar de cualquier CPU.

Mi problema se resolvió después de cambiarlo a x86.

Esto también puede suceder simplemente por tener múltiples marcos compatibles definido en el aplicación.config y obligar a la aplicación a ejecutarse en un marco .NET diferente al que mencionado primero en el archivo app.config.

Y también esto se activa cuando tiene los dos marcos mencionados disponibles en su sistema.

Como solución alternativa, abra el marco de destino que va a utilizar para la depuración en app.config

ej: si intenta ejecutar en .NET 4, el archivo de configuración debería tener algo similar a esto,

<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>

En mi proyecto para C#, propiedad del proyecto->[Construir]->Objetivo de plataforma: cualquier CPU, y desmarque Preferir 32 bits para permitir que el compilador elija automáticamente.

También tuve este problema al ejecutar pruebas unitarias usando ReSharper en Visual Studio 2017 y lo arreglé con la siguiente configuración:

También puede cambiar la configuración de la prueba de ejecución de ReSharper: https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64-configuration

¡Disparo! Sabía de este problema. Pensé que estaba haciendo todo bien hasta que accidentalmente vi 'x86' en la ventana de salida de VS y fue entonces cuando me di cuenta de la causa. Perdí unos minutos en eso hoy.

La configuración en la ventana 'Publicar' se estableció en 'x86'; mientras que, en todas partes, era 'x64'.

Asegúrese de que esté sincronizado en el administrador de configuración, la configuración de publicación, la configuración de la solución y la configuración de IIS (si ese es su servidor web).

Además, tenga en cuenta que VS es una aplicación de 32 bits e IIS es de 64 bits. Las aplicaciones de 32 bits están deshabilitadas de forma predeterminada en IIS.

Puede ser un poco divertido, pero tuve el mismo problema con el código de trabajo normal. Agregué StreamWriter y StreamReader y dio ese error. La solución fue que tomé ese código entre paréntesis de comentarios, luego lo depuré y comenzó a funcionar nuevamente.

Si usa LibreOffice desde su programa a través de la integración cli .net como yo, tengo el mismo error. Uso la versión anterior de LibreOffice en el entorno de producción de mi PC. Instalé una versión más nueva que estaba en conflicto. Simplemente desinstale LibreOffice. Encontré la solución aquí .NET CLI: no se pudo cargar el archivo o ensamblado 'cli_cppuhelper'

En mi caso, faltaba una dependencia en el dll que lanzó esta excepción. Verifiqué con Dependency Walker, agregué el dll que faltaba y el problema se resolvió.

Más específicamente, de alguna manera corrompí mi opencv_core340.dll al agregarle accidentalmente palabras clave SVN y, por lo tanto, mi dll ya no pudo usarlo. Sin embargo, no creo que la solución a este problema dependa de si el dll está dañado o falta. Solo estoy agregando esto por el bien de dar información completa.

He detectado algo diferente a las otras respuestas. Alcanzar esta excepción en mi proyecto fue el resultado de una compilación corrupta. Sin hacer ningún cambio, solo obligando a reconstruir, se arregló.

Tuve el mismo problema. El proyecto B en mi caso era una biblioteca de clases .Net Core que tiene instalado un Nuget "Microsoft.Management.Infrastructure". El error fue que llamé a mi proyecto B "MI". Cambié el nombre del proyecto a otro y de repente todo volvió a funcionar.

¿Está intentando ejecutar su archivo .exe desde el cmd? Este fue mi error. Simplemente ejecute el archivo .exe haciendo doble clic en él. Si es un SCD de .NET Core para Windows 8.1/Windows Server 2012 R2 x64.

En mi caso el error fue System.BadImageFormatException: no se pudo cargar el archivo o ensamblado 'vjslib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' o una de sus dependencias.

Se solucionó instalando vjredist 64 desde aquí.

Mi máquina me mostró una actualización del BIOS y me preguntaba si eso tiene algo que ver con la aparición repentina de este error. Y después de que hice la actualización, el error se resolvió y la solución funcionó bien.