Warum sollte eine .NET EXE, die als x86 kompiliert wurde, als x64 ausgeführt werden?

9

Ich habe ein einfaches Befehlszeilenprogramm, das in C # geschrieben ist, unter .NET 4.0 läuft und mit Visual Studio 10.0 kompiliert wird.

Was es tut, ist, Daten aus der Datei Access.mdb eines anderen Anbieters zu ziehen und sie in eine Sql Server-Datenbank einzufügen, damit eine unserer Apps auf die Daten zugreifen kann.

Wir verwenden die OleDbConnection / OleDbCommand / OleDbDataReader-Klassen von .NET unter Verwendung von Microsoft.Jet.OLEDB.4.0 als Datenanbieter.

Das hat für uns gut funktioniert, bis wir versucht haben, auf 64-Bit-Rechnern zu laufen. Es stellt sich heraus, dass es keinen 64-Bit-OleDb-Provider für .NET gibt. Es gibt vage, halbklare Threads zu dem Problem, das überall im Web verstreut ist, mit Diskussionen über verschiedene Versionen von Access, oder MDAC, oder Office, oder was auch immer, das die Dinge für einige Leute irgendwie funktioniert hat.

Wir haben das Projekt so konfiguriert, dass es x86 als Ziel hat. Und das Problem ging weg.

Jetzt ist es zurück, aus Gründen, die ich einfach nicht verstehe. Wenn ich das Programm auf meinem lokalen Computer erstelle, läuft es als x86, aber wenn ich es auf unserem Build-Rechner erstelle, läuft es als x64.

Die Projektdatei ist eindeutig für x86:

konfiguriert %Vor%

Es wird aus derselben Batchdatei erstellt, egal ob auf meinem Computer oder auf dem Erstellungscomputer:

%Vor%

Und die generierten exes sagen sie sind x86, unabhängig davon, auf welchem ​​Rechner sie gebaut sind. Wenn ich dumpbin / header auf einem der beiden ausführe, sehe ich:

%Vor%

Der einzige Unterschied zwischen den Dumps einer auf meinem Rechner erstellten Exe und einer auf dem Build-Rechner erstellten Exe ist der Zeitstempel und der Pfad zur .pdb-Datei.

Aber, und hier ist die seltsame Sache, eine exe, die auf meinem Rechner gebaut wird, läuft gut, einer, der auf dem Build-Rechner aufgebaut ist, mit derselben Fehlermeldung, die wir gesehen hatten, als wir es als x64 gebaut hatten.

Mehr als das - unser Programm erhält seine Konfiguration von der Registrierung und für den Komfort des Benutzers, wenn es keine Einstellung findet, erstellt es eine. Wir lesen sie und erstellen sie in HLM \ SOFTWARE \ OurName \ OurApp. Da es sich jedoch um eine 32-Bit-App handelt, die auf einer 64-Bit-Maschine ausgeführt wird, sollte sie wirklich von HLM \ SOFTWARE \ WoW6432Node \ OurName \ OurApp lesen und schreiben.

Und mit den Apps, die auf meinem Rechner installiert sind, funktioniert es. Aber die Apps, die auf dem Erstellungscomputer erstellt wurden, obwohl sie für x86 kompiliert wurden und Header haben, die angeben, dass sie als x86 ausgeführt werden sollen, lesen und schreiben von HLM \ SOFTWARE \ OurName \ OurApp und nicht von HLM \ SOFTWARE \ WoW6432Node \ OurName \ OurApp. Als ob es trotz allem tatsächlich als 64-Bit-App lief.

Hat jemand eine Idee, wie das passieren könnte?

    
Jeff Dege 21.05.2012, 19:36
quelle

1 Antwort

5

OK, das ist nur ärgerlich.

Was wir in der .csproj-Datei hatten, war folgendes:

%Vor%

Dies ergibt sich aus der Übernahme der Standardkonfiguration und ihrer Änderung in Ziel x86.

Ich habe die AnyCPU-Konfigurationen entfernt und neue x86-Konfigurationen erstellt und folgendes erhalten:

%Vor%

Nun hätte ich schwören können, dass die GUI mir gesagt hat, dass ich x86 sowohl in Debugging als auch in Release in der alten Konfiguration anvisiere. Und die resultierenden ausführbaren Dateien wurden als x86 dekomprimiert und als x86 auf meinem Computer ausgeführt. Aber anscheinend war ich verwirrt darüber, welche Versionen der EXE unter welchen Bedingungen gebaut wurden, denn wenn man sich die .csproj anschaut, ist es klar, dass wir beim Erstellen der Veröffentlichung nicht x86 angegeben haben.

In jedem Fall werden die exes mit der neuen Konfiguration erstellt und ausgeführt, unabhängig davon, auf welchem ​​Rechner sie erstellt wurden oder auf welchem ​​sie ausgeführt werden.

In jedem Fall, tut mir leid, dass ich Sie beunruhigt habe, und danke, dass Sie mir das Ohr gegeben haben, das mich dazu gebracht hat, das Problem richtig zu betrachten.

    
Jeff Dege 21.05.2012, 22:12
quelle