Clickonce: BadImageFormatException beim Laufen x86-Paket auf 64-Bit-Windows

Question

Meine .NET 2.0-Anwendung Importen nicht verwaltete 32-Bit-DLL. Die DLL wird geladen (erste Interop-Aufruf geschieht), wenn der Benutzer eine Datei über einen Dialog innerhalb der Anwendung öffnet sich.

Wenn ich die Anwendung über Clickonce mit Zielplattform „Any“ bereitstellen, Benutzer auf 64-Bit-Windows BadImageFormatException beim Versuch Dateien aus der Anwendung zu öffnen (im Moment der nicht verwalteten DLL geladen ist). Ich verstehe dies incompabible Bitness des 64-Bit-Prozess zurückzuführen ist und der 32-Bit-unmanaged dll.

Ich habe die Anwendung mit x86 als Zielplattform umgeschichtet. Wie ich es verstehe, sollte dies das Bitness Problem lösen.

Wenn ich die Einsatz Anwendung für x86 auf 64-Bit-System gebaut laufen, bekomme ich jetzt BadImageFormatException unmittelbar vor der Anwendung selbst beginnt. Getestet auf mindestens drei 64-Bit-Maschinen. Auf 32-Bit-Maschinen, funktioniert es ohne Probleme.

Wenn ich die Anwendung ausführen direkt aus VS (oder auch nicht direkt, nur eine normale Statur, nicht über Clickonce zu gehen), gibt es kein Problem auf 64-Bit-Windows, wenn x86 Zielplattform. Die Anwendung startet und Anwender können Datei laden -. Der Interop-Aufruf erfolgreich

Ich habe dies bereits das Debuggen für 2 Tage gerade ohne Ergebnis - habe ich versucht, auf verschiedenen Computern. Es scheint, die Arbeit an einem der Computer consistentnly ich versucht habe. Allerdings habe ich nicht permanent Zugriff auf diesen Computer.

Ich habe es geschaffen, die Clickonce-Bereitstellung auf meinem Computer einmal zu bauen und es funktioniert auf einer 64-Bit-Maschine. Dies war Single von vielleicht 100 versucht! Nichts hat sich geändert, die nur geändert Variable war, dass ich den erfolgreichen Build sofort nach dem Neustart des Computers hat.

Ich habe sauber / rebuild / Neustart VS / windows viele Male neu starten. Ich habe VS 2008 neu installiert und nun auch das ganze Betriebssystem, es hat nicht geholfen.

---

EDIT: Ich habe gerade geschaffen, eine gute bauen zu bekommen (außer nächsten 100 :)) und tat Vergleich zwischen den bereitgestellten Verzeichnissen. Die Ursache des Problems ist, dass Clickonce die falsche Zielplattform in dem Manifest der Haupt EXE erzeugt:

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

processor sollte x86.

Die Frage ist also, wie konsequent VS zu zwingen, die richtige processor im Manifest zu erzeugen, wenn bereitstellen.

Kann mir jemand bitte helfen?

Answer 1

Dies wird durch die Installation von VS 2008 SP1 auf 64-Bit-Windows-7 VS2008 SP1 auf XP gelöst wurde das Problem auf zwei Maschinen hatte ich mit habe versucht.

Answer 2

Ich hatte dieses Problem auch, VS2008 SP1 verwenden. In meinem Fall hatte ich ein 32-Bit-DLL, die als 32-Bit und eine Anwendung erstellt werden mußten, dass es in der gleichen Lösung wurde mit. Auch wenn ich X86 als Build-Ziel für das Release-Build angegeben, wenn ich eine 64-Bit-Anwendung veröffentlicht wurde im Installationsprogramm zusammengestellt und enthielt. Ich fand eine etwas brutale Lösung für das Problem: Gehen Sie in den Konfigurationsmanager und entfernen Sie alle möglichen Konfigurationen außer der, die Sie wollen, dass es bauen (Debug und Release-Versionen). Nachdem Sie das getan fand ich, dass das Clickonce-Installationsprogramm mit der korrekten Anwendung generiert wurde.

Ich hoffe, das hilft jemand anderes, ich habe auf und ab für Monate dieses Problem wurde kämpfen.

Answer 3

Ich würde verwenden vorschlagen Reflector die Haupt-exe von Clickonce bereitgestellt zu öffnen und sehen die Abhängigkeiten sicherstellen, dass Sie nicht die 64-Bit-Version der dLL versehentlich bereitstellen.

Answer 4

Sie lösen müssen 32-Bit-Anwendungen in IIS 7. Siehe http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

Answer 5

Manchmal scheint der Clickonce-Publishing-Prozess alte Dateien aus früheren zwischenzuspeichern Jede CPU oder x64 Builds. eines sauberen tun und Wiederaufbau haben beheben All dieses Problem nicht für mich. Ich brauchte die gesamten ist und obj Ordner von meinen Projekten zu löschen und Visual Studio wieder öffnen.

Answer 6

Wir liefen in dieses Problem und festgestellt, dass das Unterverzeichnis des Benutzerprofils auf dem Clickonce unsere Anwendung bereitgestellt beschädigt wurden müssen, weil wir in der Lage waren, die Anwendung erfolgreich mit Clickonce bereitstellen, wenn sie als ein anderer Benutzer auf dem gleichen Rechner angemeldet .

Wir waren in der Lage, das Problem einfach zu lösen, indem das Unterverzeichnis von C:\Users\<user>\AppData\Local\Apps Löschen, unter denen unsere Clickonce-Anwendung wurde bereitstellen. In unserem Fall wurde diese C:\Users\<user>\AppData\Local\Apps\2.0.