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

Tengo dos proyectos, ProjectA y ProjectB . ProjectB es una aplicación de consola, que depende de ProjectA . Ayer, todo estaba funcionando bien, pero de repente hoy cuando ejecuto ProjectB obtengo esto:

BadImageFormatException no fue manejado :
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 progtwig con un formato incorrecto.

Ambos son solo proyectos regulares, sin dependencias en ningún otro proyecto que no sea .Net. Ambos son completamente .Net – no hay un código nativo, y no hay P / Invoke. Tengo otros proyectos que dependen de ProjectA y todavía funcionan bien.

Cosas que he intentado:

  • Asegúrese de que ambos proyectos estén configurados en “Cualquier CPU”, con la checkbox de comstackción activada. Son.
  • Asegúrese de que ambos proyectos sean para el mismo Target Framework (.Net 4.0 Client Profile) .
  • En ProjectB -> Referencias -> ProjectA -> Propiedades, asegúrese de que “Copiar local” esté configurado en “True” _ (verifiqué que ProjectA.dll se está copiando correctamente)
  • Limpiar / reconstruir la solución. Incluso traté de eliminar manualmente las carpetas / bin y / obj en ambos proyectos.
  • Reinicie Visual Studio. Reinicia mi computadora.
  • Vea una copia completamente nueva del repository.

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

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

Podría ser 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 las 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. En el panel derecho, haz clic en Configuración avanzada …
  5. Establezca Habilitar aplicaciones de 32 bits en True

enter image description here

Acabo de tener este mensaje de error ejecutando 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 el Proyecto web.

Yo tuve el mísmo problema. Establecí el “Objetivo de la plataforma” del Proyecto A (“Proyecto A” (clic derecho) -> Propiedades-> Construir -> “Objetivo de la plataforma”) en x86, pero mantuve el Proyecto B en “Cualquier CPU”. Establecer el Proyecto B en “x86” solucionó esto.

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

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

Es posible que necesite cambiar la configuración del conjunto de aplicaciones “Habilitar aplicaciones de 32 bits” a TRUE en IIS7 si tiene al menos 1 dll \ exe de 32 bits en su proyecto.

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

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”).

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

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

Lo obtuve al construir un proyecto a través de Visual Studio Online (VSTS) Build usando Visual Studio Build Steps.

La solución fue:

  • Eliminar la carpeta de origen existente
  • Establezca explícitamente ‘Cualquier CPU’ en la plataforma para todas las comstackciones de Visual Studio, incluidas las dependencias (consulte la captura de pantalla a continuación).
  • Vuelve a ejecutar la construcción

VSO Captura de pantalla

Me encontré con 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 aplicación (el proyecto que hace referencia a todos los otros proyectos) a una CPU de destino de x86. Ahora funciona

No estoy seguro de cómo se produjo la mezcla de CPU de destino sin motivo aparente, pero lo hizo.

También enfrento 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 , simplemente vaya a las propiedades del proyecto y luego seleccione Comstackr desde la barra lateral y habrá 5 menús desplegables, el quinto desplegable será la CPU de destino: debe establecerlo 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 teniendo definidos varios marcos admitidos en el archivo app.config y forzando a la aplicación a ejecutarse en un marco .NET diferente al mencionado primero en el archivo app.config .

Y también esto se dispara cuando tienes los dos frameworks mencionados disponibles en tu sistema.

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

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

   

En mi proyecto para C #, project property -> [Build] -> Platform target: Cualquier CPU, y desmarque el Prefer 32 bit para que el comstackdor pueda elegir automáticamente.

El ensamblado Chilkat .NET 4.5 requiere que el tiempo de ejecución de VC ++ 2012 o 2013 se instale 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 ha instalado Visual Studio. Sin embargo, si se implementa en una computadora donde el tiempo de ejecución requerido de VC ++ no está disponible, se producirá el error anterior:

Instale todos los paquetes 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

Antes que nada, obtuve esto en VS2017 con un proyecto antiguo que necesitaba para hacer un pequeño cambio y reubicamos todos los proyectos en el framework 4.7.


Varios otros mencionaron seleccionar Any CPU puede solucionar este problema.

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

1) Necesitas hacer ambas cosas aquí:

enter image description here

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

enter image description here

Pero ¿y si no está allí?

A continuación, haga clic en New y elija estas configuraciones: ( gracias @RckLN )

enter image description here

Si utiliza LibreOffice de su progtwig a través de la integración de cli .net como yo, tengo el mismo error. Utilizo la versión anterior de LibreOffice en el entorno de producción en mi PC. Instalé una versión más nueva que estaba en conflicto. Solo desinstale LibreOffice. Encontré la solución aquí .NET CLI: No se pudo cargar el archivo o ensamblado ‘cli_cppuhelper’

Puede ser un poco gracioso, 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 en corchetes de comentarios, luego depuré y comenzó a funcionar de nuevo

También tuve este problema al ejecutar pruebas unitarias usando ReSharper en Visual Studio 2017 y lo solucioné con las siguientes configuraciones:

enter image description here

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

Mi máquina me mostró una actualización de la 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, se resolvió el error y la solución fue bien construida.

¿Estás tratando de ejecutar tu 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.

    Intereting Posts