2012-01-25 16 views
83

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.Solución de problemas BadImageFormatException

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

Esto es lo que he probado hasta ahora:

  • verificado la configuración de creación como plataforma de destino son todos del mismo (86).
  • Peverify usado 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 usa 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: 
+0

¿Qué es xxxDevices? –

+0

¿estás mezclando código nativo/.net en absoluto? –

+1

Está en el camino correcto que esta excepción está asociada con las diferencias de bit x86/x64. Supongo que esto no es una aplicación web, ¿verdad? Además, ¿qué tipo de ensamblaje es 'XxxDevicesService'? ¿Está compilado para una plataforma específica (por ejemplo, 32 bits)? Si es así, entonces debes compilar tu plataforma a 32 bits. – Reddog

Respuesta

99

verificado la configuración de creación como plataforma de destino son todos del mismo (86).

eso no es lo que el registro de bloqueo dice:

Asamblea gestor de carga desde: C: \ Windows \ Microsoft.NET \ Framework64

Nota del 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.

+5

Y mientras comprueba el proyecto EXE, compruebe Debug * y * Release. :/ – chris

11

Normalmente puede ocurrir cuando modificó el marco de destino de .csproj y lo revierte a lo que comenzó.

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

Asegúrate 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 incompatibilidades de 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 cosas diferentes con las propiedades del proyecto para superar el error.

+0

Encontré un problema similar y su respuesta fue la solución para el mío. Mi app.config tenía un tiempo de ejecución soportado diferente. –

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 funcionó bien

+0

Lo mismo aquí. Esto hizo el truco. Hace referencia a un ensamblaje de 64 bits y la configuración de compilación activa se configuró en Cualquier CPU, pero debido a esta configuración de "preferencia de 32 bits", se usó supuestamente 32 bits ejecutando la aplicación y causó los problemas. –

3

He solucionado este problema al cambiar la aplicación web para usar un "grupo de aplicaciones" diferente.

5

También puede conseguir este objetivo excepción cuando su aplicación .NET Framework 4.5 (por ejemplo) y que 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.

2

Para cualquier persona 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 adicional de la aplicación y funcionó.

+0

Me lo arreglaron. ¡Mi App.config estaba configurando mi aplicación .NET 4.5.1 en el 2.0 CLR! –

2

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

28

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, solía copias de los archivos DLL que trabajaron para otros en diferentes aplicaciones, me puse la base de código en el ensamblado dependiente para que apunte a la carpeta bin de mi proyecto, he intentado CopyLocal como verdadera o falsa, Intenté todo. Finalmente hice suficiente trabajo como para verificar mi código y como nuevo contratista no tuve 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.

+0

¡Gracias, esto ha solucionado un problema con pdfium para mí! – Akinzekeel

+2

¡Qué salvavidas! Gracias. Para mí tuve que verificar esto, ya que mi proyecto es efectivamente x64. ¡¡¡Gracias de nuevo!!! – viper

+0

Después de toda la ayuda que he recibido aquí, estoy muy contento de haber podido pagar algo de esto. –

1

Al compilar 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.

0

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

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

3

Antecedentes

Empezamos a recibir esto hoy cuando cambiamos nuestro servicio WCF desde Cualquier CPU a x64 en un servidor de Windows 2012 R2 correr IIS 6.2.

Primero revisamos el único conjunto al que se hace referencia 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. Resulta que los grupos de aplicaciones en IIS estaban configurados por defecto en un valor Habilitar 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 aplicación.
  • Elija Establecer valores predeterminados del grupo de aplicaciones ... o Configuración avanzada ....
  • Cambiar Habilite las aplicaciones de 32 bits en True.
  • Haga clic en Aceptar.
  • Elija Establecer valores predeterminados del grupo de aplicaciones ... o Configuración avanzada ... nuevamente.
  • Cambiar Habilitar aplicaciones de 32 bits volver a False.
  • Haga clic en Aceptar.
8

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.

0

Cuando me enfrenté a este problema los siguientes resuelto por mí:

estaba llamando un DLL OpenCV desde el interior de otro exe, mi DLL no contenían los archivos DLL OpenCV ya necesarios como highgui, features2d, y etc disponible en la carpeta de mi archivo exe Copié todo esto al directorio de mi proyecto exe y de repente funcionó.

0

eliminamos su dependencia de System.Runtime en su Web.Config, que trabajó 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> 
0

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

  1. Asegúrese de que el AppPool en el que se ejecuta 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 el ensamblaje en Visual Studio apunta 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 deberse a que WSODLibs se promociona con el proyecto web.
0

Para .NET Core, hay una Visual Studio 2017 bug que pueden causar las propiedades del proyecto Construir la página para mostrar la plataforma de destino incorrecto. 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.

Como alternativa, puede agregar un identificador de tiempo de ejecución al .csproj. Si necesita que su .exe para funcionar como x 86 para que se pueda cargar un archivo DLL nativo x86, añadir este elemento dentro de un PropertyGroup:

<RuntimeIdentifier>win-x86</RuntimeIdentifier> 

Un buen lugar para poner esto es justo después de que el elemento o TargetFrameworkTargetFrameworks.

Cuestiones relacionadas