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


409

Tengo dos proyectos, ProjectAy ProjectB. ProjectBes una aplicación de consola, que depende de ProjectA. Ayer, todo funcionaba bien, pero de repente hoy cuando corro ProjectBme sale esto:

BadImageFormatException no se manejó :
no se pudo cargar el archivo o ensamblado 'ProjectA, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' o una de sus dependencias. Se intentó cargar un programa con un formato incorrecto.

Ambos son solo proyectos regulares, sin dependencias de ningún otro proyecto que no sea .Net. Ambos son completamente .Net: no hay código nativo ni P / Invoke. Tengo otros proyectos que dependen ProjectAy aún funcionan bien.

Cosas que he probado:

  • Asegúrese de que ambos proyectos estén configurados en "Cualquier CPU", con la casilla de verificación de compilación marcada. Son.
  • Asegúrese de que ambos proyectos sean para el mismo Marco de destino (.Net 4.0 Client Profile) .
  • En ProjectB -> Referencias -> ProjectA -> Propiedades, asegúrese de que "Copiar local" esté configurado en "Verdadero" _ (verifiqué que ProjectA.dll se está copiando correctamente)
  • Limpiar / reconstruir la solución. Incluso intenté eliminar manualmente las carpetas / bin y / obj en ambos proyectos.
  • Reinicie Visual Studio. Reiniciar mi computadora.
  • Echa un vistazo a una copia completamente nueva del repositorio.

Pero sigo teniendo el mismo error. No tengo idea de qué hice para causar esto, ni cómo solucionarlo. ¿Algunas ideas?


1
Si tiene un historial de versiones en el repositorio, ¿podría verificar si hay algunas diferencias en los archivos csproj?
Steve

@Steve: Según Mercurial, no hay cambios más que agregar referencias a nuevos archivos .cs
BlueRaja - Danny Pflughoeft

¿Obtiene el mismo comportamiento en otra máquina? ¿Ha cambiado algo más en la máquina (por ejemplo, actualización de Windows, actualizaciones de dependencia, etc.)?
Mike Parkhill

¿Has intentado revertir esos nuevos archivos .cs?
Mike Parkhill

2
Esto funcionó para mí ............ stackoverflow.com/a/9419522/191403
Som

Respuestas:


647

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


71
Do'h De alguna manera me falta por completo el menú desplegable "objetivo de plataforma" project-->properties-->build, se configuró para x86; establecerlo en "Cualquier CPU" solucionó este problema. Siempre pensé que esta configuración era la misma que la del menú desplegable "objetivo de plataforma" en el administrador de configuración, pero aparentemente no lo es (de hecho, el "objetivo de plataforma" en el administrador de configuración no parece hacer nada en absoluto)
BlueRaja - Danny Pflughoeft

10
También verifique que el proyecto no sea Cualquier CPU con Preferencia de 32 bits marcada. Proyecto -> propiedades -> construir
Reid Evans

26
PD: Otra razón es "Habilitar aplicaciones de 32 bits" como "falso" en la configuración del grupo de aplicaciones. Debe reiniciar IIS después de establecerlo en verdadero.
dvdmn

3
Lo peor que me sucedió con este error fue cuando VS decidió agregarse <PlatformTarget>x86</PlatformTarget>a uno de los proyectos dependientes sin ningún motivo. Si no hubiera investigado SVN, nunca habría descubierto por qué nuestra aplicación MVC no se inicia.
jahu

1
Configure en IIS DefaultAppPool-> Habilitar aplicaciones de 32 bits = Verdadero
Shantu

197

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

Luego debe ajustar su grupo de aplicaciones para habilitar aplicaciones de 32 bits .

Pasos

  1. Abra el administrador de IIS
  2. Haga clic en Grupos de aplicaciones
  3. Seleccione el grupo de aplicaciones que esté utilizando
  4. Desde el panel derecho, haga clic en Configuración avanzada ...

  5. Establezca Habilitar aplicaciones de 32 bits en Verdadero

    Ajustes avanzados Habilitar 32 bits


1
¿Me he perdido algo? OP habla de una aplicación de consola, no de un despliegue de IIS: "ProjectB es una aplicación de consola, que depende de ProjectA"
MickyD

129

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:

Captura de pantalla de las opciones de VS para Web Project.


2
Lo contrario se aplica a, tuve el 'Uso de 64 bits' marcado y necesitaba que untick ...
cjb110

32

Yo tuve el mísmo problema. Había establecido el "Objetivo de plataforma" del Proyecto A ("Proyecto A" (clic derecho) -> Propiedades-> Compilación -> "Objetivo de plataforma") en x86 pero mantuve el Proyecto B en "Cualquier CPU". Establecer el Proyecto B en "x86" solucionó esto.


15

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

7

Es posible que necesite cambiar la appication piscina ajuste "Habilitar 32 bits Aplicaciones" a TRUE en IIS7 si tiene al menos 1 de 32 bits DLL \ exe en su proyecto.


OP habla de una aplicación de consola no de IIS
MickyD

5

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


Varios otros han mencionado que la selección Any CPUpuede solucionar este problema.

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

1) Tienes que hacerlo tanto aquí:

ingrese la descripción de la imagen aquí

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

ingrese la descripción de la imagen aquí

Pero, ¿y si no está allí?

Luego haga clic Newy elija esta configuración: ( gracias @RckLN )

ingrese la descripción de la imagen aquí


2

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


1
Trabajó en Release pero falló en Debug. Establezca todo en .Net Framework 4 (NO Actualización 1) y la depuración se ejecuta ahora.
DCastenholz

2

También puede ver este problema si está intentando empaquetar un proyecto de 64 bits con un instalador MSI en VS. ("La razón es porque el shim nativo empaquetado con el archivo .msi es un ejecutable de 32 bits").

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


1
Considere resumir el artículo vinculado para beneficio de futuros lectores; en caso de que el enlace se corte.
Bond - Java Bond

2

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


2

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

La solución fue:

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

Captura de pantalla de VSO


2

Lo siguiente resolvió el problema para mí, desmarque 'Preferir 32 bits': ingrese la descripción de la imagen aquí


1

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

En la instantánea de Excepción, para el 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 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 ocurrió la confusión de CPU de destino sin razón aparente, pero lo hizo.


1

También me enfrento a 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á utilizando Visual Studio 2010 o VS 2013 , simplemente vaya a las propiedades del proyecto y luego seleccione Compilar en la barra lateral y habrá 5 desplegables, el quinto desplegable será CPU objetivo: debe 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.


1

Esto también puede suceder simplemente al tener múltiples marcos soportados definidos en el archivo app.config y forzando a la aplicación a ejecutarse en un marco .NET diferente al que se menciona primero en el archivo app.config .

Y esto también se dispara cuando tiene ambos marcos mencionados disponibles en su sistema.

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

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"/>

1

En mi proyecto para C #, propiedad del proyecto -> [Build] -> Target de plataforma: cualquier CPU, y desmarque Prefer 32-bit para permitir que el compilador elija automáticamente.


1

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

Instale todos los paquetes de abajo

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



0

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



0

En mi caso faltaba una dependencia en el dll que arrojó esta excepción. Verifiqué con Dependency Walker, agregué el dll faltante 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 podía 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 en aras de dar información completa.


0

¡Disparar! Sabía sobre 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 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: VS es una aplicación de 32 bits e IIS es de 64 bits. Las aplicaciones de 32 bits están deshabilitadas de manera predeterminada en IIS.

ingrese la descripción de la imagen aquí


0

He detectado algo diferente de las otras respuestas. Llegar a esta excepción en mi proyecto fue el resultado de una compilación corrupta. Sin hacer ningún cambio, solo forzando la reconstrucción , se solucionó.


0

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


-1

Mi máquina me mostró una actualización del BIOS y me pregunté 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 se compiló bien.


-1

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.