c# - could not load file or assembly or one of its dependencies
No se pudo cargar el archivo o conjunto... Se intentó cargar un programa con un formato incorrecto(System.BadImageFormatException) (22)
Tengo dos proyectos, ProjectA
y ProjectB
. ProjectB
es una aplicación de consola, que depende de ProjectA
. Ayer, todo funcionaba bien, pero de repente, hoy cuando ejecuto ProjectB
, obtengo esto:
BadImageFormatException no fue manejado :
No se pudo cargar el archivo o el ensamblaje ''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 en ningún otro proyecto fuera de la red. Ambos son totalmente .Net: no hay código nativo ni P / Invoke. Tengo otros proyectos que dependen de ProjectA
y todavía 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 traté de eliminar manualmente las carpetas / bin y / obj en ambos proyectos.
- Reinicie Visual Studio. Reinicie mi computadora
- Echa un vistazo a una copia completamente nueva del repositorio.
Pero sigo teniendo el mismo error. No tengo idea de lo que hice para causar esto, ni de cómo solucionarlo. ¿Algunas ideas?
¿Estás intentando ejecutar tu archivo .exe desde el cmd? Este fue mi error. Simplemente ejecute el archivo .exe haciendo doble clic en él. Si es un .NET Core SCD para Windows 8.1 / Windows Server 2012 R2 x64.
Acabo de recibir 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 "Use la versión de 64 bits de IIS Express para sitios web y proyectos".
Captura de pantalla:
El ensamblaje Chilkat .NET 4.5 requiere que el tiempo de ejecución de 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 ha instalado Visual Studio. Sin embargo, si se implementa en una computadora donde el tiempo de ejecución de VC ++ 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
En mi caso, faltaba una dependencia en la dll que lanzó esta excepción. Verifiqué con Dependency Walker, agregué la DLL que faltaba y el problema se resolvió.
Más específicamente, de alguna manera corrompí mi opencv_core340.dll al agregar 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 la DLL está dañada o no. Solo estoy agregando esto con el fin de dar información completa.
En mi proyecto para C #, propiedad del proyecto -> [Generar] -> Objetivo de la plataforma: cualquier CPU, y desmarque Preferir 32 bits para permitir que el compilador elija automáticamente.
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 seleccionar Any CPU
puede solucionar este problema.
Hay un par de lugares donde debes hacerlo, y puede que no sea tan simple como seleccionar en el menú desplegable. Esto me lo arregló:
1) Necesitas hacerlo tanto aquí:
2) Y también en Configuration Manager
(clic derecho en la solución)
Pero ¿y si no está ahí?
Luego haga clic en New
y elija estas configuraciones: ( gracias @RckLN )
Es posible que deba cambiar la configuración del grupo de aplicaciones "Activar aplicaciones de 32 bits" a VERDADERO en IIS7 si tiene al menos 1 dll / exe de 32 bits en su proyecto.
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:
- Abra el Administrador de IIS
- Haga clic en Grupos de aplicaciones
- Seleccione cualquier grupo de aplicaciones que esté utilizando
- En el panel derecho, haga clic en Configuración avanzada ...
- Establecer Habilitar aplicaciones de 32 bits en Verdadero
Esto también puede suceder simplemente teniendo múltiples marcos compatibles definidos en el archivo app.config y obligando a la aplicación a ejecutarse en un marco .NET diferente al que se menciona 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, muestre el marco de destino que va a utilizar para la depuración en app.config
Por ejemplo: 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"/>
Estoy bastante seguro de que está teniendo 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 de SO y esta también . Entre los dos, deberías poder resolver tu problema.
Me encontré con el mismo problema. Apareció de la nada y eso me pareció extraño.
En la instantánea de excepción, para el FusionLog, vi lo siguiente en su mensaje:
... C: / Windows / Microsoft.NET / Framework64 ...
Más información 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 objetivo 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 mezcla de CPU de destino sin razón aparente, pero lo hizo.
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 desarrolló correctamente.
Ninguna de estas soluciones funcionó para mí, pero al eliminar el contenido de las carpetas bin y obj, todo volvió a ser genial.
Obtuve esto cuando construí un proyecto a través de Visual Studio Online (VSTS) Build usando Visual Studio Build
Steps.
La solución fue:
- Eliminar la carpeta fuente existente
- Establezca explícitamente ''Cualquier CPU'' en la plataforma para todas las versiones de Visual Studio, incluidas las dependencias (vea la captura de pantalla a continuación).
- Vuelva a ejecutar la compilación
Puede ser un poco divertido, pero tuve el mismo problema con el código de trabajo normal. Agregué StreamWriter y StreamReader y di ese error. La solución fue que tomé ese código en corchetes de comentarios, luego hice la depuración y comenzó a funcionar de nuevo.
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 desde la barra lateral y habrá 5 desplegables, 5º desplegable será Target CPU:, 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.
También puede ver este problema si está intentando empaquetar un proyecto de 64 bits con un instalador MSI en VS. ("El motivo 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
También tuve este problema al ejecutar pruebas unitarias utilizando ReSharper en Visual Studio 2017 y lo arreglé con la siguiente configuración:
También puede cambiar la configuración de prueba de ejecución del ReSharper: https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64-configuration
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ó con éxito.
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
Yo tuve el mísmo problema. Había establecido 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". Al establecer el Proyecto B en "x86" se solucionó esto.
Si usa LibreOffice desde su programa a través de la integración de cli .net como yo, obtuve 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 reciente que estaba en conflicto. Simplemente desinstale LibreOffice. Encontré la solución aquí .NET CLI: No se pudo cargar el archivo o el ensamblaje ''cli_cppuhelper''