558 Stimmen

Wie behebe ich den Visual Studio-Kompilierungsfehler "Unstimmigkeit zwischen Prozessorarchitekturen"?

Ich bin neu bei der Projektkonfiguration in Visual Studio 2010, aber ich habe einige Recherche betrieben und kann dieses Problem immer noch nicht ganz verstehen. Ich habe eine Visual Studio-Lösung mit einem C++-DLL, das auf das C#-DLL verweist. Das C#-DLL verweist auf einige andere DLLs, einige innerhalb meines Projekts und einige externe. Wenn ich versuche, das C++-DLL zu kompilieren, erhalte ich diese Warnung:

Warnung MSB3270: Es gab einen Konflikt zwischen der Prozessorarchitektur des zu erstellenden Projekts "MSIL" und der Prozessorarchitektur der Referenz "[internes C#-DLL]", "x86".

Es sagt mir, dass ich zum Konfigurations-Manager gehen soll, um meine Architekturen abzugleichen. Das C#-DLL ist mit dem Plattformziel x86 eingerichtet. Wenn ich versuche, dies auf etwas anderes zu ändern, z. B. Any CPU, beschwert es sich, weil eine der externen DLLs, von der es abhängt, das Plattformziel x86 hat.

Wenn ich den Konfigurations-Manager anschaue, wird die Plattform für mein C#-DLL als x86 und für mein C++-Projekt als Win32 angezeigt. Dies scheint die richtige Konfiguration zu sein; sicherlich möchte ich nicht, dass das Projekt für mein C++-Projekt auf x64 festgelegt ist, was die einzige andere Option ist, die angeboten wird.

Was mache ich hier falsch?

0 Stimmen

Was ist die Beschwerde, speziell, wenn Sie es auf Any CPU ändern?

2 Stimmen

Ich habe nicht genug Informationen, um einen fundierten Vorschlag zu machen, aber mit der rechten Maustaste auf Ihre Lösung klicken -> Projekterstellungsreihenfolge und sicherstellen, dass Ihr C#-Projekt vor dem C++-Projekt erstellt wird. Wenn nicht, gehen Sie zum Register "Abhängigkeiten" und geben Sie VS Bescheid, dass das C++-Projekt vom C#-Projekt abhängt.

7 Stimmen

Visual Studio ist wieder Mist darin. Die Plattform oben auf meinem Bildschirm sagt x64, aber die Warnung besagt, dass das Projekt, das erstellt wird, "MSIL" ist. Also sagt Visual Studio mir, dass es eine Diskrepanz zwischen Äpfeln und Orangen gibt, wenn ich keine Äpfel benutze. Können wir es umbenennen in Visual Stupido?

612voto

David Sacks Punkte 6306

Diese Warnung scheint mit dem neuen Visual Studio 11 Beta und .NET 4.5 eingeführt worden zu sein, obwohl ich vermute, dass es vorher möglich war.

Erstens handelt es sich wirklich nur um eine Warnung. Es sollte nichts ausmachen, wenn Sie nur mit x86-Abhängigkeiten umgehen. Microsoft versucht Sie nur zu warnen, wenn Sie angeben, dass Ihr Projekt mit "Any CPU" kompatibel ist, aber Sie eine Abhängigkeit von einem Projekt oder einer .dll-Assembly haben, die entweder x86 oder x64 ist. Aufgrund einer x86-Abhängigkeit ist Ihr Projekt technisch gesehen daher nicht mit "Any CPU" kompatibel. Um die Warnung zu beseitigen, sollten Sie tatsächlich Ihr Projekt von "Any CPU" auf "x86" ändern. Dies ist sehr einfach zu tun, hier sind die Schritte.

  1. Gehen Sie zum Menüpunkt Build|Konfigurations-Manager.
  2. Finden Sie Ihr Projekt in der Liste, unter Plattform wird "Any CPU" stehen.
  3. Wählen Sie die Option "Any CPU" aus dem Dropdown-Menü und wählen Sie dann
  4. Wählen Sie in diesem Dialogfeld x86 aus dem Dropdown-Menü "Neue Plattform" aus und stellen Sie sicher, dass "Any CPU" im Dropdown-Menü "Einstellungen kopieren von" ausgewählt ist.
  5. Klicken Sie auf OK
  6. Sie möchten sowohl für die Debug- als auch für die Release-Konfiguration x86 auswählen.

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

Noch eine Anmerkung: Projekte können normalerweise "Any 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, das auf eine bestimmte Prozessorarchitektur zielt.

3 Stimmen

Ich habe gerade die RTW von Visual Studio 2012 installiert und eine bereits vorhandene Lösung von 2010 geöffnet und angefangen, die gleiche Warnung zu sehen, also ist es etwas, das immer noch in der RTW vorhanden ist.

7 Stimmen

Das gesagt, ich denke, Davids Antwort ist korrekt, diese Warnung zeigt Ihnen an, dass Ihre App wirklich nicht "AnyCPU" ist, sodass Sie auf Probleme stoßen werden, wenn Sie sie schließlich auf die falsche Architektur bereitstellen.

9 Stimmen

Es könnte durchaus etwas kaputt machen. Eine beliebige CPU-Datei wird auf einem 64-Bit-Betriebssystem als x64 geladen und kann x86-DLLs nicht laden. Wenn Sie also von einer bestimmten Plattform abhängig sind, sollten Sie Ihre Plattform wirklich korrekt einstellen.

164voto

Gio Punkte 1994

Dies ist eine sehr hartnäckige Warnung und obwohl es eine gültige Warnung ist, gibt es einige Fälle, in denen sie aufgrund der Verwendung von Komponenten von Drittanbietern und anderen Gründen nicht behoben werden kann. Ich habe ein ähnliches Problem, außer dass die Warnung darauf zurückzuführen ist, dass die Plattform meiner Projekte AnyCPU ist und ich eine von AMD64 erstellte MS-Bibliothek referenziere. Das passiert übrigens in Visual Studio 2010 und scheint durch die Installation von VS2012 und .Net 4.5 eingeführt zu werden.

Da ich die von mir referenzierte MS-Bibliothek nicht ändern kann und da ich weiß, dass meine Zielbereitstellungsumgebung immer nur 64-Bit sein wird, kann ich diese Warnung sicher ignorieren.

Was ist mit der Warnung? Microsoft hat als Reaktion auf einen Connect-Bericht gepostet, dass eine Option darin besteht, diese Warnung zu deaktivieren. Dies sollten Sie nur tun, wenn Sie sich sehr über die Architektur Ihrer Lösung im Klaren sind und Ihr Bereitstellungsziel vollständig verstehen und wissen, dass es außerhalb der Entwicklungsumgebung kein wirkliches Problem darstellt.

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

  None

1 Stimmen

Die einzige andere offizielle MS-Referenz zu dieser Lösung, die ich gesehen habe, befindet sich in der Microsoft .NET Framework 4.5 RC Readme-Datei. Seltsamerweise wurde sie aus der RTM-Readme-Datei entfernt.

4 Stimmen

Das funktioniert, aber nicht für eine Variation der Warnung: "Referenzierte Assembly ... zielt auf einen anderen Prozessor als die Anwendung". Es wäre großartig, wenn es eine ähnliche Einstellung für diese Warnung gäbe?

9 Stimmen

"Meine Projektplattform ist AnyCPU und ich verweise auf eine MS-Bibliothek, die für AMD64 erstellt wurde"... Das ist FALSCH. Da Ihr Zielbereitstellung immer 64-Bit ist, können Sie Ihre Plattform auf x64 setzen, was bei einer Verletzung Ihrer 64-Bit-Annahme einen angemesseneren Fehler ergibt und auch die Warnung verhindert.

73voto

Gustavo Mori Punkte 8033

Eine gute Faustregel lautet: "Öffne DLLs, schließe EXEs", das heißt:

  • EXE zielt auf das Betriebssystem ab, indem es x86 oder x64 angibt.
  • DLLs bleiben offen (d.h. AnyCPU), damit 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 Prozessbitanz vom Betriebssystem verwendet wird, das die EXE nach Bedarf JIT. Das heißt, ein x64-Betriebssystem erstellt einen 64-Bit-Prozess, ein x86-Betriebssystem erstellt einen 32-Bit-Prozess.

Das Erstellen von DLLs als AnyCPU macht sie mit beiden Prozessen kompatibel.

Weitere Informationen zu den Feinheiten des Assembly-Ladens finden Sie unter hier. Die Zusammenfassung lautet ungefähr wie folgt:

  • AnyCPU – wird als x64- oder x86-Assembly geladen, abhängig vom aufrufenden Prozess
  • 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

4 Stimmen

Dieser Regel erscheint mir logisch. Aber betrachten Sie die folgende Situation: Native.dll (x64) verwendet von NetA.dll (Any CPU) verwendet von NetB.dll (Any CPU) verwendet von App1.exe (x64). Hier gibt es kein echtes Problem, aber beim Kompilieren von NetA.dll erscheint mir die Warnung. Okay, da diese Assembly direkt von Native.dll abhängig ist, könnte ich sie auch als x64 markieren. Aber dann beschwert sich die Kompilierung von NetB.dll. Ich möchte NetB.dll als "Any CPU" beibehalten, da es eine gemeinsame Assembly ist, die in einer anderen reinen .NET-Anwendung verwendet wird. Ich komme zu dem Schluss, dass meine einzige Option darin besteht, die Warnung zu unterdrücken/ignorieren. Richtig?

2 Stimmen

Aufgrund der Abhängigkeit von Native.dll ist Ihre gesamte App/Assembly-Lineage jetzt x64, ob Sie die Warnung unterdrücken oder nicht. Während die Unterdrückung in Ihrem Szenario funktioniert, könnten in Zukunft seltsame Situationen auftreten. Zum Beispiel wird 1) die Assembly NetB in einer x86-Umgebung verwendet, in der Nativex64 nicht geladen wird, oder 2) Ihr Kunde möchte eine x86-Version von App1.exe, und Sie kompilieren glücklich, da NetB als beliebiger CPU markiert ist, aber wieder wird Nativex64 oben im Stapel nicht geladen.

0 Stimmen

Während die Regel von Gustavo ein guter Grundsatz ist, kann sie für das spezifische Problem, das in dieser Frage gestellt wird, nicht verwendet werden, da das Projekt bereits von einer Abhängigkeit zu einer Drittanbieter-Assembly abhängt, die die Regel nicht befolgt hat (es handelt sich um x86, nicht AnyCPU). Daher müssen solange die Abhängigkeit besteht, alle Projektketten auf x86 und nichts anderes abzielen.

24voto

Hans Passant Punkte 894572

Die C# DLL ist mit dem Zielplattform x86 eingerichtet

Das ist irgendwie das Problem, eine DLL kann tatsächlich nicht wählen, welche Bittiefe der Prozess haben wird. Das wird ausschließlich vom EXE-Projekt bestimmt, das die erste Assembly ist, die geladen wird, sodass dessen Einstellung für die Zielfläche zählt und die Bittiefe für den Prozess festlegt.

Die DLLs haben keine Wahl, sie müssen mit der Bittiefe des Prozesses kompatibel sein. Wenn sie es nicht sind, erhalten Sie bei dem Versuch, sie zu verwenden, eine große Ausnahme mit einer BadImageFormatException.

Also ist eine gute Auswahl für die DLLs AnyCPU, damit sie auf jede Weise funktionieren. Das macht viel Sinn für C# DLLs, sie funktionieren tatsächlich auf jede Weise. Aber sicherlich nicht für Ihre C++/CLI-Mixed-Mode-DLL, sie enthält nicht verwalteten Code, der nur gut funktionieren kann, wenn der Prozess im 32-Bit-Modus läuft. Sie können das Bausystem dazu bringen, Warnungen darüber zu generieren. Genau das haben Sie bekommen. Nur Warnungen, es wird trotzdem ordnungsgemäß gebaut.

Verschieben Sie einfach das Problem. Legen Sie das Zielplattform des EXE-Projekts auf x86 fest, es wird mit keiner anderen Einstellung funktionieren. Und behalten Sie einfach alle DLL-Projekte bei AnyCPU.

1 Stimmen

Also, um es klar zu sagen: Ich erstelle nicht die EXE, sondern ich erstelle eine DLL, die mit der EXE einer anderen Person ausgeführt wird. Wenn ich das Plattformziel der C#-DLLs auf Any CPU ändere, wird die Warnung nicht beseitigt. Ich frage mich, ob dies ein Fall von connect.microsoft.com/VisualStudio/feedback/details/728901/… ist - Ich würde die Warnung selbst ignorieren, aber tatsächlich kann die EXE die C#-DLL laden, nicht jedoch die C++-DLL, also denke ich, dass dies ein echtes Problem ist.

0 Stimmen

Benutzen Sie tatsächlich VS2010? Es war auch überhaupt nicht klar, dass Sie die C++/CLI DLL nicht laden konnten. Was ist die Diagnose? Aktualisieren Sie Ihre Fragen mit diesen wesentlichen Informationen.

0 Stimmen

Hatte nicht über den Ladefehler gepostet, weil ich nicht zu 100% sicher war, dass es damit zusammenhängt, und bei weiterem Debugging stellt sich heraus, dass es nicht so ist. Ich benutze VS2010. Frage-Text aktualisiert. Entschuldigung für die Verwirrung.

9voto

yogeshwar gutte Punkte 119

Ich habe die gleiche Warnung erhalten, als ich Folgendes gemacht habe:

  1. Projekt entladen

  2. Projekteigenschaften bearbeiten, d.h. .csproj-Datei

  3. Fügen Sie das folgende Tag hinzu:

            None
  4. Projekt wieder laden

5 Stimmen

Das löst das Problem nicht. Es deaktiviert nur die Warnung für das spezielle Projekt. In manchen Fällen finde ich das aber eine gültige Lösung. Danke!

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X