Wie behebe ich den Visual Studio-Kompilierungsfehler "Nichtübereinstimmung zwischen Prozessorarchitektur"?

Ich bin neu in der Projektkonfiguration in Visual Studio 2010, habe aber einige Nachforschungen angestellt und kann dieses Problem immer noch nicht ganz herausfinden. Ich habe eine Visual Studio-Lösung mit einer C ++ - DLL, die auf die C # -DLL verweist. Die C # -DLL verweist auf einige andere DLLs, einige innerhalb meines Projekts und einige externe. Wenn ich versuche, die C ++ - DLL zu kompilieren, wird folgende Warnung angezeigt:

Warnung MSB3270: Es gab eine Nichtübereinstimmung zwischen der Prozessorarchitektur des zu erstellenden Projekts "MSIL" und der Prozessorarchitektur der Referenz "[interne C # dll]", "x86".

Ich muss zu Configuration Manager gehen, um meine Architekturen auszurichten. Die C # -DLL wird mit dem Plattformziel x86 eingerichtet. Wenn ich versuche, dies in etwas anderes zu ändern, wie z. B. eine beliebige CPU, beschwert es sich, weil eine der externen DLLs, von denen es abhängt, das Plattformziel x86 hat.

Wenn ich mir Configuration Manager anschaue, wird die Plattform für meine C # -DLL als x86 und für mein C ++ - Projekt als Win32 angezeigt. Dies scheint das richtige Setup zu sein. Sicherlich möchte ich nicht, dass für das Projekt für mein C ++ - Projekt die Plattform auf x64 eingestellt ist. Dies ist die einzige andere Option, die angeboten wird.

Was mache ich hier falsch?

Diese Warnung scheint mit dem neuen Visual Studio 11 Beta und .NET 4.5 eingeführt worden zu sein, obwohl dies vermutlich schon früher möglich war.

Erstens ist es wirklich nur eine Warnung. Es sollte nichts schaden, wenn Sie nur mit x86-Abhängigkeiten zu tun haben. Microsoft versucht nur, Sie zu warnen, wenn Sie angeben, dass Ihr Projekt mit "Beliebige CPU" kompatibel ist, Sie jedoch von einem Projekt oder einer DLL-Assembly abhängig sind, die entweder x86 oder x64 ist. Da Sie eine x86-Abhängigkeit haben, ist Ihr Projekt technisch nicht mit "Any CPU" kompatibel. Damit die Warnung verschwindet, sollten Sie Ihr Projekt von "Beliebige CPU" auf "x86" ändern. Dies ist sehr einfach, hier sind die Schritte.

1. Wechseln Sie zum Menüpunkt Build | Configuration Manager.
2. Suchen Sie Ihr Projekt in der Liste. Unter Plattform wird "Beliebige CPU" angezeigt.
3. Wählen Sie die Option "Beliebige CPU" aus der Dropdown-Liste und wählen Sie dann <New..>
4. Wählen Sie in diesem Dialogfeld x86 aus der Dropdown-Liste "Neue Plattform" aus und stellen Sie sicher, dass in der Dropdown-Liste "Einstellungen kopieren von" die Option "Beliebige CPU" ausgewählt ist.
5. Klicken Sie auf OK
6. Sie sollten x86 sowohl für die Debug- als auch für die Release-Konfiguration auswählen.

Dadurch wird die Warnung ausgeblendet und es wird angegeben, dass Ihre Assembly oder Ihr Projekt jetzt nicht mehr mit "Any CPU" kompatibel ist, sondern jetzt x86-spezifisch. Dies gilt auch, wenn Sie ein 64-Bit-Projekt mit einer x64-Abhängigkeit erstellen. Sie würden stattdessen einfach x64 auswählen.

Ein weiterer Hinweis: Projekte können normalerweise mit "jeder CPU" kompatibel sein, wenn es sich um reine .NET-Projekte handelt. Dieses Problem tritt nur auf, wenn Sie eine Abhängigkeit (Drittanbieter-DLL oder Ihr eigenes C ++ - verwaltetes Projekt) einführen, die auf eine bestimmte Prozessorarchitektur abzielt.

Dies ist eine sehr hartnäckige Warnung, und obwohl es sich um eine gültige Warnung handelt, gibt es einige Fälle, in denen sie aufgrund der Verwendung von Komponenten von Drittanbietern und aus anderen Gründen nicht behoben werden kann. Ich habe ein ähnliches Problem, außer dass die Warnung darin besteht, dass meine Projektplattform AnyCPU ist und ich auf eine für AMD64 erstellte MS-Bibliothek verweise. Dies ist übrigens in Visual Studio 2010 und scheint durch die Installation von VS2012 und .Net 4.5 eingeführt zu werden.

Da ich die MS-Bibliothek, auf die ich verweise, nicht ändern kann und ich weiß, dass meine Zielbereitstellungsumgebung immer nur 64-Bit sein wird, kann ich dieses Problem ignorieren.

Was ist mit der Warnung? Microsoft hat als Antwort auf einen Connect-Bericht veröffentlicht, dass eine Option darin besteht, diese Warnung zu deaktivieren. Sie sollten dies nur tun, wenn Sie sich Ihrer Lösungsarchitektur sehr bewusst sind und Ihr Bereitstellungsziel vollständig verstehen und wissen, dass es sich nicht wirklich um ein Problem außerhalb der Entwicklungsumgebung handelt.

Sie können Ihre Projektdatei bearbeiten und diese Eigenschaftsgruppe und Einstellung hinzufügen, um die Warnung zu deaktivieren:

<PropertyGroup>
  <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>

Eine gute Faustregel lautet "offene DLLs, geschlossene EXE-Dateien", dh:

• EXE zielt auf das Betriebssystem ab, indem x86 oder x64 angegeben wird.
• DLLs bleiben offen (dh AnyCPU), sodass sie innerhalb eines 32-Bit- oder 64-Bit-Prozesses instanziiert werden können.

Wenn Sie eine EXE als AnyCPU erstellen, verschieben Sie lediglich die Entscheidung darüber, welche Prozessbitness für das Betriebssystem verwendet werden soll, wodurch die EXE nach ihren Wünschen JIT wird. Das heißt, ein x64-Betriebssystem erstellt einen 64-Bit-Prozess, ein x86-Betriebssystem erstellt einen 32-Bit-Prozess.

Durch das Erstellen von DLLs als AnyCPU sind sie mit beiden Prozessen kompatibel.

Weitere Informationen zu den Feinheiten beim Laden von Baugruppen finden Sie hier . Die Zusammenfassung lautet wie folgt:

• AnyCPU - wird je nach Aufrufprozess als x64- oder x86-Assembly geladen
• x86 - wird als x86-Assembly geladen; wird nicht von einem x64-Prozess geladen
• x64 - wird als x64-Assembly geladen; wird nicht von einem x86-Prozess geladen

Die C # -DLL wird mit dem Plattformziel x86 eingerichtet

Was das Problem ist, kann eine DLL nicht auswählen, wie hoch der Prozess sein soll. Dies wird vollständig vom EXE-Projekt bestimmt. Dies ist die erste Assembly, die geladen wird, sodass die Plattform-Zieleinstellung die Bitanzahl für den Prozess zählt und festlegt.

Die DLLs haben keine Wahl, sie müssen mit der Prozessbitness kompatibel sein. Wenn dies nicht der Fall ist, erhalten Sie einen großen Kaboom mit einer BadImageFormatException, wenn Ihr Code versucht, sie zu verwenden.

Eine gute Auswahl für die DLLs ist also AnyCPU, sodass sie in beide Richtungen funktionieren. Das macht viel Sinn für C # DLLs, sie tun Arbeit entweder Weg. Aber sicher, nicht Ihre C ++ / CLI-DLL im gemischten Modus, sondern nicht verwalteten Code, der nur dann gut funktioniert, wenn der Prozess im 32-Bit-Modus ausgeführt wird. Sie können das Build-System dazu bringen, Warnungen darüber zu generieren. Welches ist genau das, was du hast. Nur Warnungen, es baut immer noch richtig.

Stoßen Sie einfach auf das Problem. Setzen Sie das Plattformziel des EXE-Projekts auf x86, es funktioniert mit keiner anderen Einstellung. Und behalten Sie einfach alle DLL-Projekte bei AnyCPU.

Ich bekam die gleiche Warnung, die ich getan habe:

1. Projekt entladen
2. Bearbeiten Sie die Projekteigenschaften, z. B. .csproj

3. Fügen Sie das folgende Tag hinzu:

   <PropertyGroup>
       <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
           None
       </ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
   </PropertyGroup>

4. Laden Sie das Projekt neu

Ich hatte heute dieses Problem und es half nicht, nur die Gebäudekonfigurationen in Visual Studio zu betrachten, da jede CPU sowohl für das nicht erstellte Projekt als auch für das referenzierte Projekt angezeigt wurde.

Ich habe dann im csproj des referenzierten Projekts nachgesehen und Folgendes gefunden:

<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>x64</PlatformTarget>

Irgendwie wurde dieses PlatformTarget mitten in einer Konfigurationsänderung hinzugefügt und die IDE schien es nicht zu sehen.

Das Entfernen dieser Zeile aus dem referenzierten Projekt hat mein Problem gelöst.

Wenn Ihre C # -DLL x86-basierte Abhängigkeiten aufweist, muss Ihre DLL selbst x86 sein. Ich sehe keinen Weg daran vorbei. VS beschwert sich über die Änderung in (zum Beispiel) x64, da eine ausführbare 64-Bit-Datei keine 32-Bit-Bibliotheken laden kann.

Ich bin etwas verwirrt über die Konfiguration des C ++ - Projekts. Die Warnmeldung, die für den Build bereitgestellt wurde, deutet darauf hin, dass er für AnyCPU bestimmt war, da die Plattform, auf die er abzielte, [MSIL] war. Sie haben jedoch angegeben, dass die Konfiguration für das Projekt tatsächlich Win32 war. Eine native Win32-App sollte die MSIL nicht einbeziehen - obwohl wahrscheinlich die CLR-Unterstützung aktiviert sein muss, wenn sie mit einer C # -Bibliothek interagiert. Ich denke also, dass es auf der Informationsseite einige Lücken gibt.

Könnte ich Sie mit Respekt bitten, die genaue Konfiguration der Projekte und ihre Wechselbeziehung zu überprüfen und etwas detaillierter zu veröffentlichen? Helfen Sie gerne weiter, wenn möglich.

Zusätzlich zur Antwort von David Sacks müssen Sie möglicherweise auch auf die BuildRegisterkarte von gehen Project Propertiesund für das Projekt festlegen Platform Target, x86das Ihnen diese Warnungen gibt. Obwohl dies zu erwarten ist, scheint diese Einstellung nicht perfekt mit der Einstellung im Konfigurationsmanager synchronisiert zu sein.

Bei C # -Projekten macht das Ziel von x86 das, wonach es sich anhört. Es heißt, dass diese Assembly nur x86-Architekturen unterstützt. Ebenso für x64. Jede CPU hingegen sagt, dass es mir egal ist, welche Architektur ich beide unterstütze. Die nächsten beiden Fragen lauten also: (1) Wie ist die Konfiguration der ausführbaren Datei, die diese DLLs verwendet? und (2) was ist die BissigkeitIhres Betriebssystems / Computers? Der Grund, den ich frage, ist, dass wenn Ihre ausführbare Datei für die Ausführung in 64-Bit kompiliert ist, alle Abhängigkeiten erforderlich sind, um auch im 64-Bit-Modus ausgeführt werden zu können. Ihre Any CPU-Assembly sollte geladen werden können, verweist jedoch möglicherweise auf eine andere Abhängigkeit, die nur in der x86-Konfiguration ausgeführt werden kann. Überprüfen Sie alle Abhängigkeiten und Abhängigkeiten von Abhängigkeiten, um sicherzustellen, dass alles entweder "Beliebige CPU" oder "x64" ist, wenn Sie die ausführbare Datei im 64-Bit-Modus ausführen möchten. Andernfalls treten Probleme auf.

In vielerlei Hinsicht macht Visual Studio das Kompilieren einer Mischung aus einer beliebigen CPU und verschiedenen architekturabhängigen Assemblys nicht einfach. Dies ist machbar, erfordert jedoch häufig, dass eine Assembly, die ansonsten "Beliebige CPU" wäre, für x86 und x64 separat kompiliert werden muss, da eine Abhängigkeit von einer Abhängigkeit irgendwo zwei Versionen hat.

Ich hatte zuvor ein ähnliches Problem, insbesondere beim Hinzufügen einer Testlösung zu einer vorhandenen x64-Lösung wie SharePoint. In meinem Fall scheint dies damit zu tun zu haben, dass bestimmte Projektvorlagen standardmäßig als bestimmte Plattformen hinzugefügt werden.

Hier ist die Lösung, die bei mir häufig funktioniert: Stellen Sie im Configuration Manager (die aktive Konfigurations-Dropdown-Liste ist laut Debug normalerweise ein guter Weg, um dorthin zu gelangen) und auf der Projektplattform (in den Projekteigenschaften) alles auf die richtige Plattform ein Build, dann setzen Sie alles zurück auf AnyCPU. Manchmal muss ich einige Abhängigkeiten entfernen und erneut hinzufügen (DLLs in den Eigenschaften jedes Projekts), und manchmal muss der "Tests in 32-Bit- oder 64-Bit-Prozess ausführen" (Doppelklicken Sie auf Local.testsettings und gehen Sie zu Hosts) geändert werden.

Es scheint mir, dass dies nur etwas setzt und dann zurücksetzt, aber hinter den Kulissen, die ich nicht sehe, ist wahrscheinlich mehr los. Es hat in der Vergangenheit ziemlich konsequent für mich funktioniert.

Für mein Projekt muss ich in der Lage sein, sowohl auf x86 als auch auf x64 zu bauen. Das Problem dabei ist, dass jedes Mal, wenn Sie Referenzen hinzufügen, während Sie eine verwenden, es sich beschwert, wenn Sie die andere erstellen.

Meine Lösung besteht darin, die * .csproj-Dateien manuell so zu bearbeiten, dass folgende Zeilen angezeigt werden:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=AMD64"/>

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL"/>

werde dazu geändert:

<Reference Include="MyLibrary.MyNamespace, Version=1.0.0.0, Culture=neutral"/>

Ich hatte ein ähnliches Problem, das durch die MS UNIT Test DLL verursacht wurde. Meine WPF-Anwendung wurde als x86 kompiliert, die Unit-Test-DLL (referenzierte EXE-Datei) jedoch als "Beliebige CPU". Ich habe die Unit-Test-DLL so geändert, dass sie für x86 (wie EXE) kompiliert wird, und sie wurde neu erstellt.

Möglicherweise erhalten Sie diese Warnung auch für MS Fakes-Assemblys, die nicht so einfach zu lösen ist, da der Befehl f.csproj auf basiert. Glücklicherweise können Sie die Fakes-XML dort hinzufügen .

Es sollte eine Möglichkeit geben, eine .NET EXE / DLL AnyCPU und alle nicht verwalteten DLLs zu erstellen, die sowohl mit x86 als auch mit x64 kompiliert werden müssen. Beide werden möglicherweise mit unterschiedlichen Dateinamen gebündelt, und dann lädt das .NET-Modul basierend auf seiner Laufzeit dynamisch die richtige Prozessorarchitektur. Das würde AnyCPU leistungsfähig machen. Wenn die C ++ - DLL nur x86 oder x64 unterstützt, ist AnyCPU natürlich sinnlos. Die Idee, beide Bündelungen zu bündeln, die ich noch nicht umgesetzt habe, da der Konfigurationsmanager nicht einmal die Möglichkeit bietet, dasselbe Projekt zweimal mit einer anderen Konfiguration / Plattform für mehrere Bündelungen zu erstellen, sodass AnyCPU oder sogar andere Konzepte wie jede Konfiguration möglich sind.

Ich hatte eine sehr ähnliche Warnung in meinem Build. Meine Projekte waren auf .NET 4.5 ausgerichtet. Auf dem Build-Server wurde das Windows 8.1 SDK (für .NET 4.5.1) installiert. Nachdem ich meine Projekte auf .NET 4.5.1 aktualisiert hatte (war für mich kein Problem, war für eine völlig neue Anwendung), erhielt ich keine Warnung mehr ...

Ich habe diese Warnung behoben und "Configuration Manager" in "Release" (Mixed Plataform) geändert.

Diese Warnung wurde in Visual Studio 2012 beim Kompilieren einer SQL Server 2012 SP1-SSIS-Pipeline-Skriptaufgabe angezeigt - bis ich SQL Server 2012 SP2 installiert habe.

Ich hatte das gleiche Problem mit dem Öffnen der SQLite-Verbindung, und die Verwendung des Nuget und die Installation der im Projekt verwendeten Komponente (SQLite) haben das Problem behoben! Versuchen Sie, Ihre Komponente auf diese Weise zu installieren, und überprüfen Sie das Ergebnis

Verwenden Sie https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-example :

• Fügen Sie Ihrem Lösungsordner eine Directory.Build.props- Datei hinzu
• füge dies ein:

<Project>
 <PropertyGroup>
   <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
 </PropertyGroup>
</Project>