ClickOnce: BadImageFormatException cuando se ejecuta el paquete x86 en ventanas de 64 bits

Question

Mi aplicación .NET 2.0 importa dll de 32 bits no administrados. El dll se carga (se produce la primera llamada de interoperabilidad) cuando el usuario abre un archivo a través de un cuadro de diálogo dentro de la aplicación.

Cuando implemento la aplicación a través de clickonce con la plataforma de destino " Any " ;, los usuarios en ventanas de 64 bits obtienen BadImageFormatException cuando intentan abrir archivos desde la aplicación (en este momento se carga el dll no administrado) . Entiendo que esto se debe a la incompatibilidad del proceso de 64 bits y el dll no administrado de 32 bits.

He redistribuido la aplicación usando x86 como plataforma de destino. Según tengo entendido, esto debería resolver el problema del bitness.

PERO

Cuando ejecuto la aplicación desplegada creada para x86 en un sistema de 64 bits, ahora recibo BadImageFormatException inmediatamente antes de que la aplicación se inicie. Probado en al menos tres máquinas de 64 bits. En máquinas de 32 bits, funciona sin problemas.

Cuando ejecuto la aplicación directamente desde VS (o no directamente, solo una compilación normal, no a través de ClickOnce), no hay ningún problema en las ventanas de 64 bits cuando utilizo la plataforma de destino x86. La aplicación se inicia y el usuario puede cargar el archivo: la llamada de interoperabilidad se realiza correctamente.

He estado depurando esto durante 2 días seguidos sin ningún resultado, lo he intentado en diferentes computadoras. Parece funcionar consistentemente en una de las computadoras que he probado. Sin embargo, no tengo acceso permanente a esta computadora.

He logrado construir la implementación ClickOnce en mi computadora una vez y funcionó en una máquina de 64 bits. ¡Esto fue solo de quizás 100 intentos! Nada ha cambiado, la única variable cambiada fue que hice la compilación exitosa inmediatamente después de reiniciar la computadora.

Limpié / reconstruí / reinicié VS / reinicié Windows MUCHAS veces. He reinstalado VS 2008 y ahora también todo el sistema operativo, no ayudó.

---

EDITAR: acabo de lograr una buena compilación (de las siguientes 100 :)) e hice una comparación entre los directorios implementados. El origen del problema es que ClickOnce genera la plataforma de destino incorrecta en el manifiesto del .exe principal:

<asmv1:assemblyIdentity name="app.exe" version="1.0.4.18" publicKeyToken=".token here." language="neutral" processorArchitecture="<b>msil</b>" type="win32" />

procesador La arquitectura debe ser x86.

Entonces, la pregunta es cómo forzar constantemente a VS a generar la arquitectura del procesador correcta en el manifiesto al desplegarse.

¿Alguien puede ayudar por favor?

Answer 1

Esto se resolvió instalando VS 2008 SP1 en Windows 7 de 64 bits. VS2008 SP1 en XP tenía el problema en dos máquinas con las que he probado.

Answer 2

También tuve este problema al usar VS2008 SP1. En mi caso, tenía una DLL de 32 bits que tenía que compilarse como 32 bits y una aplicación que la estaba usando en la misma solución. Aunque especifiqué X86 como destino de compilación para la compilación de lanzamiento, cuando publiqué una aplicación de 64 bits se compiló e incluyó en el instalador. Encontré una solución ligeramente brutal al problema: Vaya al administrador de configuración y elimine todas las configuraciones posibles, excepto la que desea que se compile (versiones de depuración y lanzamiento). Después de hacer esto, descubrí que el instalador de clickonce se generó con la aplicación correcta.

Espero que esto ayude a alguien más, he estado luchando contra este problema durante meses.

Answer 3

Sugeriría usar Reflector para abrir el exe principal desplegado por ClickOnce y ver el dependencias para asegurarse de que no está implementando la versión de 64 bits de la DLL por error.

Answer 4

Debe resolver ejecutar aplicaciones de 32 bits en IIS 7. Consulte http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

Answer 5

A veces, el proceso de publicación ClickOnce parece almacenar en caché los archivos antiguos de cualquier CPU anterior o compilaciones x64. Hacer una limpieza y reconstruir todo no solucionó este problema para mí. Necesitaba eliminar todas las carpetas bin y obj de mis proyectos y volver a abrir Visual Studio.

Answer 6

Nos encontramos con este problema y determinamos que el subdirectorio del perfil de usuario en el que ClickOnce implementó nuestra aplicación debe haberse dañado, porque pudimos implementar la aplicación con éxito con ClickOnce cuando iniciamos sesión como un usuario diferente en la misma máquina .

Pudimos resolver el problema simplemente eliminando el subdirectorio de C:\Users\<user>\AppData\Local\Apps bajo el cual ClickOnce estaba implementando nuestra aplicación. En nuestro caso, esto fue C:\Users\<user>\AppData\Local\Apps\2.0.