try practices handling exceptions example custom catch best c# .net exception

c# - practices - Solución de problemas de BadImageFormatException



throw exception c# (16)

Las configuraciones de compilación verificadas, como el objetivo de la plataforma, son todas iguales (x86).

Eso no es lo que dice el registro de fallos:

Administrador de ensamblaje cargado desde: C: / Windows / Microsoft.NET / Framework64

Tenga en cuenta el 64 en el nombre, ese es el hogar de la versión de 64 bits del marco. Establezca la configuración de la plataforma de destino en su proyecto EXE , no su proyecto de biblioteca de clase. El proyecto EXE de XxxDevicesService determina la bitidez del proceso.

Tengo un servicio de Windows escrito en C # utilizando Visual Studio 2010 y apuntando a .NET Framework 4. Cuando ejecuto desde una compilación de depuración el servicio se ejecuta como se esperaba. Sin embargo, cuando lo ejecuto desde una versión de Release obtengo una System.BadImageFormatException (detalles a continuación). He estado buscando una solución en Internet, pero hasta ahora todo lo que he encontrado no me ha ayudado a encontrar una solución.

El problema existe en los sistemas de Windows 7 de 64 bits (dev) y Windows XP SP3 de 32 bits (de destino).

Esto es lo que he intentado hasta ahora:

  • Las configuraciones de compilación verificadas, como el objetivo de la plataforma, son todas iguales (x86).
  • Se usó peverify con la opción / verbose para garantizar que los archivos binarios de ensamblaje fueran válidos.
  • Utiliza fuslogvw para buscar cualquier problema de carga.
  • Se utiliza CheckAsm para buscar archivos o conjuntos faltantes.

Todos estos controles no cambiaron nada. He incluido el texto completo de la información de excepción a continuación, con algunos de los nombres modificados para proteger los secretos de mis maestros corporativos.

System.BadImageFormatException was unhandled Message=Could not load file or assembly ''XxxDevices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'' or one of its dependencies. An attempt was made to load a program with an incorrect format. Source=XxxDevicesService FileName=XxxDevices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null FusionLog=Assembly manager loaded from: C:/Windows/Microsoft.NET/Framework64/v4.0.30319/clr.dll Running under executable c:/Dev/TeamE/bin/Release/XxxDevicesService.vshost.exe --- A detailed error log follows. === Pre-bind state information === LOG: User = XXX LOG: DisplayName = XxxDevices, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null (Fully-specified) LOG: Appbase = file:///c:/Dev/TeamE/bin/Release/ LOG: Initial PrivatePath = NULL Calling assembly : XxxDevicesService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. === LOG: This bind starts in default load context. LOG: Using application configuration file: c:/TeamE/bin/Release/XxxDevicesService.vshost.exe.Config LOG: Using host configuration file: LOG: Using machine configuration file from C:/Windows/Microsoft.NET/Framework64/v4.0.30319/config/machine.config. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: Attempting download of new URL file:///c:/TeamE/bin/Release/XxxDevices.DLL. ERR: Failed to complete setup of assembly (hr = 0x8007000b). Probing terminated. StackTrace: at XxxDevicesService.Program.Main(String[] args) at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args) at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Threading.ThreadHelper.ThreadStart() InnerException:

Al crear aplicaciones para plataformas de 32 o 64 bits (Mi experiencia es con Visual Studio 2010), no confíe en Configuration Manager para establecer la plataforma correcta para el ejecutable. Incluso si el CM tiene x86 seleccionado para la aplicación, verifique las propiedades del proyecto (pestaña Construir): aún podría decir "Cualquier CPU" allí. Y si ejecuta un ejecutable "Any CPU" en una plataforma de 64 bits, se ejecutará en modo de 64 bits y se rehusará a cargar los archivos DLL que lo acompañan que fueron creados para la plataforma x86.

Cuando me enfrenté a este problema, lo siguiente lo resolví para mí:

Estaba llamando a un dll de OpenCV desde otro exe, mi dll no contenía los dlls de opencv ya necesarios, como highgui, features2d y etc., disponibles en la carpeta de mi archivo exe. Copié todo esto al directorio de mi proyecto exe y de repente funcionó.

Después de dejar de golpear mi cabeza en el escritorio pensando en toda la semana que pasé corriendo este problema, estoy compartiendo lo que funcionó para mí. Tengo Win7 64 bit, Oracle Client de 32 bits y tengo mi proyecto MVC 5 configurado para ejecutarse en la plataforma x86 debido a la bitness de Oracle. Seguí recibiendo los mismos errores:

No se pudo cargar el archivo o ensamblado ''Oracle.DataAccess'' o una de sus dependencias. Se intentó cargar un programa con un formato incorrecto.

Recargué los paquetes NuGet, utilicé copias de las DLL que funcionaban para otros en diferentes aplicaciones, configuré la base de código en el ensamblado dependiente para apuntar a la carpeta bin de mi proyecto, probé CopyLocal como verdadero o falso, lo intenté todo. Finalmente, hice lo suficiente. Quería verificar mi código y, como nuevo contratista, no tenía configuración de subversión. Mientras buscaba la manera de conectarlo a VS, tropecé con la respuesta. Lo que encontré funcionó fue desmarcar la opción "Usar la versión de 64 bits de IIS Express para sitios web y proyectos" en la sección Proyectos y soluciones => Proyectos web en el menú Herramientas => Opciones.

Determine el grupo de aplicaciones utilizado por la aplicación y establezca la propiedad de estableciendo Activar las aplicaciones de 32 bits en True. Esto puede hacerse a través de configuraciones avanzadas del grupo de aplicaciones.

Elimine su dependencia de System.Runtime en su Web.Config, funcionó para mí:

<dependentAssembly> <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.0.10.0" newVersion="4.0.10.0" /> </dependentAssembly>

Este error "No se pudo cargar el archivo o ensamblado ''ejemplo'' o una de sus dependencias. Se intentó cargar un programa con un formato incorrecto" generalmente es causado por una configuración incorrecta del grupo de aplicaciones.

  1. Asegúrese de que la AppPool en la que se está ejecutando su sitio tiene "Habilitar aplicaciones de 32 bits" establecido en False.
  2. Asegúrese de estar utilizando la versión correcta para su plataforma.
  3. Si obtiene este error en un sitio web, asegúrese de que su grupo de aplicaciones esté configurado para ejecutarse en el modo correcto (los sitios 3.0 deben ejecutarse en modo de 64 bits).
  4. También debe asegurarse de que la referencia a ese ensamblaje en Visual Studio apunte al archivo correcto en la carpeta de paquetes.
  5. Asegúrese de tener la versión correcta del dll instalado en el GAC para los sitios 2.0.
  6. Esto también puede ser causado por WSODLibs que se promocionan con el proyecto web.

Lo que encontré fue comprobar la opción "Usar la versión de 64 bits de IIS Express para sitios web y proyectos" en la sección Proyectos y soluciones => Proyectos web en el menú Herramientas => Opciones.

Normalmente puede ocurrir cuando cambiaste el marco de destino de .csproj y lo volviste a lo que comenzaste.

Asegúrese de 1 si supportedRuntime version = "un tiempo de ejecución diferente del objetivo del proyecto cs" debajo de la etiqueta de inicio en app.config.

Asegúrese de que 2 también significa verificar otros archivos autogenerados u otros archivos en la carpeta de propiedades para ver si no hay más desajuste en el tiempo de ejecución entre estos archivos y uno que está definido en el archivo .csproj.

Esto podría ahorrarle mucho tiempo antes de comenzar a probar diferentes cosas con las propiedades del proyecto para superar el error.

Para .NET Core , existe un error de Visual Studio 2017 que puede causar que la página de creación de propiedades del proyecto muestre el objetivo de la plataforma incorrecta. Una vez que descubre que el problema es, las soluciones son bastante fáciles. Puede cambiar el objetivo a algún otro valor y luego cambiarlo de nuevo.

Alternativamente, puede agregar un identificador de tiempo de ejecución al .csproj. Si necesita que su .exe se ejecute como x86 para que pueda cargar una DLL nativa x86, agregue este elemento dentro de un PropertyGroup :

<RuntimeIdentifier>win-x86</RuntimeIdentifier>

Un buen lugar para poner esto es correcto después del elemento TargetFramework o TargetFrameworks .

Para cualquiera que llegue aquí más tarde ... Nada funcionó para mí. Todas mis asambleas estaban bien. Tenía una configuración de aplicación en uno de mis proyectos de Visual Studio que no debería haber estado allí. Así que asegúrese de que el archivo de configuración de su aplicación sea necesario.

Eliminé la configuración extra de la aplicación y funcionó.

Para cualquiera que pueda llegar aquí más tarde ...
Para la solución de escritorio obtuve la excepción BadImageFormatException .
Todas las opciones de compilación del proyecto estaban bien (todas x86 ). Pero el proyecto de solución StartUp fue cambiado a algún otro proyecto (proyecto de biblioteca de clase).

Cambiar el proyecto de inicio al original (proyecto de aplicación .exe) fue una solución en mi caso

Solucioné este problema cambiando la aplicación web para usar un "grupo de aplicaciones" diferente.

También puede obtener esta excepción cuando su aplicación se dirige a .NET Framework 4.5 (por ejemplo) y tiene la siguiente app.config:

<?xml version="1.0" encoding="utf-8"?> <configuration> <startup> <supportedRuntime version="v2.0.50727" /> <supportedRuntime version="v4.0" /> </startup> </configuration>

Al intentar iniciar la depuración de la aplicación obtendrá la BadImageFormatException.

Al eliminar la línea que declara la versión v2.0 se borrará el error.

Tuve este problema recientemente cuando traté de cambiar la plataforma de destino de un antiguo proyecto .NET 2.0 a .NET 4.5.

Tuve el mismo problema aunque tengo Windows 7 de 64 bits y estaba cargando un b / c de DLL de 64 bits en las propiedades del proyecto | Build: he marcado "Prefer 32-bit". (No sé por qué está configurado por defecto). Una vez que desmarqué eso, todo salió bien

Fondo

Empezamos a recibir esto hoy cuando cambiamos nuestro servicio WCF de AnyCPU a x64 en un servidor Windows 2012 R2 que ejecuta IIS 6.2.

Primero revisamos el único ensamblaje referenciado 10 veces, para asegurarnos de que no era realmente un dll x86. A continuación, verificamos el grupo de aplicaciones muchas veces para asegurarnos de que no estaba habilitando aplicaciones de 32 bits.

En un capricho intenté alternar la configuración. Resultó que los grupos de aplicaciones en IIS estaban predeterminados a un valor de Permitir aplicaciones de 32 bits de False, pero IIS lo ignoraba en nuestro servidor por alguna razón y siempre ejecutó nuestro servicio en modo x86.

Solución

  • Seleccione el grupo de aplicaciones.
  • Elija Establecer valores predeterminados del conjunto de aplicaciones ... o Configuración avanzada ....
  • Cambie Activar aplicaciones de 32 bits a True.
  • Haga clic en Aceptar .
  • Elija Establecer valores predeterminados del conjunto de aplicaciones ... o Configuración avanzada ... de nuevo.
  • Cambie Activar aplicaciones de 32 bits a False.
  • Haga clic en Aceptar .