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

Question

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

Sie ziehen Daten aus der Access.mdb-Datei eines anderen Anbieters und fügen sie in eine Sql-Server-Datenbank ein, sodass 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.

Dies funktionierte für uns, bis wir versuchten, auf 64-Bit-Maschinen 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 wird eindeutig zum Ziel x86 konfiguriert:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> 
    <DebugType>pdbonly</DebugType> 
    <Optimize>true</Optimize> 
    <OutputPath>bin\Release\</OutputPath> 
    <DefineConstants>TRACE</DefineConstants> 
    <ErrorReport>prompt</ErrorReport> 
    <WarningLevel>4</WarningLevel> 
    <PlatformTarget>x86</PlatformTarget> 
</PropertyGroup> 

Aus der gleichen Batch-Datei integriert ist, ob auf meinem Rechner oder auf der Build-Maschine:

msbuild OurApp.sln /property:Configuration=Release 

und die erzeugen EXE-Dateien sagen Sie sie sind x86, unabhängig davon, auf welcher Maschine sie gebaut werden. Wenn ich laufe dumpbin/Header entweder, ich sehe:

FILE HEADER VALUES 
     14C machine (x86) 
      3 number of sections 
    4FBA64C8 time date stamp Mon May 21 10:52:40 2012 
      0 file pointer to symbol table 
      0 number of symbols 
      E0 size of optional header 
     102 characteristics 
       Executable 
       32 bit word machine 

Der nur Unterschied zwischen den Deponien einer exe auf meinem Rechner gebaut und eine exe-Datei auf der Build-Maschine gebaut ist der Zeitstempel und der Weg zu dem .pdb-Datei.

Aber, und hier ist die seltsame Sache, eine exe auf meinem Rechner gebaut läuft gut, baute auf der Build-Maschine Fehler mit der gleichen Fehlermeldung, die wir gesehen hatten, als wir es als x64 gebaut hatten.

Mehr als das - unser Programm erhält seine Konfiguration aus 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 einem 64-Bit-Computer ausgeführt wird, sollte sie wirklich von HLM \ SOFTWARE \ WoW6432Node \ OurName \ OurApp lesen und schreiben.

Und mit den Apps, die auf meinem Computer gebaut werden, tut 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?

Answer 1

OK, das ist nur ärgerlich.

Was wir hatten, in der.csproj Datei, war dies:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> 
    <DebugSymbols>true</DebugSymbols> 
    <DebugType>full</DebugType> 
    <Optimize>false</Optimize> 
    <OutputPath>bin\Debug\</OutputPath> 
    <DefineConstants>DEBUG;TRACE</DefineConstants> 
    <ErrorReport>prompt</ErrorReport> 
    <WarningLevel>4</WarningLevel> 
    <PlatformTarget>x86</PlatformTarget> 
</PropertyGroup> 
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "> 
    <DebugType>pdbonly</DebugType> 
    <Optimize>true</Optimize> 
    <OutputPath>bin\Release\</OutputPath> 
    <DefineConstants>TRACE</DefineConstants> 
    <ErrorReport>prompt</ErrorReport> 
    <WarningLevel>4</WarningLevel> 
</PropertyGroup> 

Es ist, was nicht daran, die Standardkonfiguration geführt und das Ändern es x86 Ziel.

entfernte ich die AnyCPU Konfigurationen und neue x86-Konfigurationen erstellt und bekam:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|x86'"> 
    <DebugSymbols>true</DebugSymbols> 
    <OutputPath>bin\x86\Debug\</OutputPath> 
    <DefineConstants>DEBUG;TRACE</DefineConstants> 
    <DebugType>full</DebugType> 
    <PlatformTarget>x86</PlatformTarget> 
    <ErrorReport>prompt</ErrorReport> 
    <CodeAnalysisIgnoreBuiltInRules>false</CodeAnalysisIgnoreBuiltInRules> 
</PropertyGroup> 
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'"> 
    <OutputPath>bin\x86\Release\</OutputPath> 
    <DefineConstants>TRACE</DefineConstants> 
    <Optimize>true</Optimize> 
    <DebugType>pdbonly</DebugType> 
    <PlatformTarget>x86</PlatformTarget> 
    <ErrorReport>prompt</ErrorReport> 
    <CodeAnalysisIgnoreBuiltInRuleSets>false</CodeAnalysisIgnoreBuiltInRuleSets> 
    <CodeAnalysisIgnoreBuiltInRules>false</CodeAnalysisIgnoreBuiltInRules> 
</PropertyGroup> 

Jetzt konnte ich geschworen habe, dass die GUI erzählte mir, ich war Targeting x86 sowohl in Debug und in Release, in der alte Konfiguration. 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 ansieht, ist es klar, dass wir beim Erstellen der Version nicht x86 angegeben haben.

In jedem Fall werden die exes mit der neuen Konfiguration erstellt und ausgeführt, unabhängig davon, auf welchem ​​Computer 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.