558 Stimmen

Wie behebe ich den Kompilierungsfehler von Visual Studio "Mismatches zwischen Prozessorarchitekturen"?

Ich bin neu in der Projektkonfiguration in Visual Studio 2010, aber ich habe einige Forschung betrieben und kann dieses Problem immer noch nicht ganz lösen. 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 eine Inkonsistenz zwischen der Prozessorarchitektur des Projekts "MSIL" und der Prozessorarchitektur des Verweises "[internes C#-DLL]", "x86".

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

Wenn ich mir den Konfigurations-Manager anschaue, zeigt er die Plattform für mein C#-DLL als x86 und für mein C++-Projekt als Win32 an. Das scheint die richtige Konfiguration zu sein; sicherlich möchte ich nicht, dass das Projekt für mein C++-Projekt auf x64 eingestellt ist, was die einzige andere Option ist, die präsentiert wird.

Was mache ich hier falsch?

0 Stimmen

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

2 Stimmen

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

7 Stimmen

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

612voto

David Sacks Punkte 6306

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

Zunächst ist es wirklich nur 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 eine Abhängigkeit von einem Projekt oder einer .dll-Assembly haben, die entweder x86 oder x64 ist. Da Sie eine x86-Abhängigkeit haben, ist Ihr Projekt technisch gesehen daher nicht "Any CPU"-kompatibel. Um die Warnung zu beseitigen, sollten Sie tatsächlich Ihr Projekt von "Any CPU" auf "x86" ändern. Das ist sehr einfach zu tun, hier sind die Schritte.

  1. Gehen Sie zum Menüpunkt Build|Configuration 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 dann wählen Sie
  4. Wählen Sie in diesem Dialogfeld x86 aus dem Dropdown-Menü "Neue Plattform" und stellen Sie sicher, dass "Any CPU" im Dropdown-Menü "Einstellungen kopieren von" ausgewählt ist.
  5. Klicken Sie auf OK
  6. Sie sollten x86 für sowohl die Debug- als auch die Release-Konfigurationen auswählen.

Dadurch verschwindet die Warnung und es wird angezeigt, dass Ihre Assembly oder Ihr Projekt jetzt nicht mehr "Any CPU"-kompatibel, sondern nun spezifisch für x86 ist. Das gilt auch, wenn Sie ein 64-Bit-Projekt erstellen, das eine x64-Abhängigkeit hat; dann würden Sie einfach x64 auswählen.

Eine weitere Anmerkung: Projekte können normalerweise mit "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++ managed Projekt) einführen, das eine spezifische Prozessorarchitektur anzielt.

3 Stimmen

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

7 Stimmen

Das gesagt, denke ich, dass Davids Antwort richtig ist, diese Warnung informiert Sie darüber, dass Ihre App tatsächlich nicht "AnyCPU" ist, sodass Sie Probleme haben werden, wenn Sie sie letztendlich auf einer falschen Architektur bereitstellen.

9 Stimmen

Es kann wirklich etwas verletzen. Eine Any-CPU-EXE 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 richtig 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 aus anderen Gründen nicht behoben werden kann. Ich habe ein ähnliches Problem, außer dass die Warnung auftritt, weil die Plattform meiner Projekte AnyCPU ist und ich eine MS-Bibliothek verwende, die für AMD64 erstellt wurde. Übrigens handelt es sich hierbei um Visual Studio 2010, und es scheint, dass dies durch die Installation von VS2012 und .Net 4.5 eingeführt wurde.

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 dieses Problem sicher ignorieren.

Was ist mit der Warnung? Microsoft hat in Antwort auf eine Connect-Meldung gepostet, dass eine Option darin besteht, diese Warnung zu deaktivieren. Sie sollten dies nur tun, wenn Sie sich sehr über die Architektur Ihrer Lösung bewusst 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 Eigenschaftsgruppe 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

Dies funktioniert, aber nicht für eine Variation der Warnung: "Verwiesene Assembly ... zielt auf einen anderen Prozessor als die Anwendung". Wäre es möglich, wenn es eine ähnliche Einstellung für diese Warnung geben würde?

9 Stimmen

"Meine Projektplattform ist AnyCPU und ich beziehe 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 einstellen, was zu einem passenderen Fehler führt, wenn Ihre Annahme von 64-Bit jemals verletzt wird, 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, 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 ein EXE als AnyCPU erstellen, verschieben Sie lediglich die Entscheidung, welche Prozessbitigkeit zu verwenden ist, auf das Betriebssystem, das das EXE nach eigenem Ermessen 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 hier. Die Zusammenfassung lautet ungefähr so:

  • AnyCPU – lädt als x64- oder x86-Assembly, abhängig vom aufrufenden Prozess
  • x86 – lädt als x86-Assembly; wird nicht aus einem x64-Prozess geladen
  • x64 – lädt als x64-Assembly; wird nicht aus einem x86-Prozess geladen

4 Stimmen

Diese Regel macht für mich Sinn. 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). Es gibt hier kein echtes Problem, aber beim Kompilieren von NetA.dll erhalte ich die Warnung. OK, da sich dieses Assembly direkt auf Native.dll bezieht, könnte ich es auch als x64 markieren. Aber dann beschwert sich das Kompilieren von NetB.dll. Ich möchte NetB.dll als "Any CPU" behalten, da es ein gemeinsames Assembly ist, das in einer anderen reinen Dot-Net-Anwendung verwendet wird. Ich komme zu dem Schluss, dass meine einzige Option darin besteht, die Warnung zu unterdrücken/ignorieren. Ja?

2 Stimmen

Aufgrund der Abhängigkeit von Native.dll ist nun Ihre gesamte App/Assembly-Linie x64, unabhängig davon, ob Sie die Warnung unterdrücken oder nicht. Obwohl die Unterdrückung in Ihrem Szenario funktioniert, könnten in Zukunft seltsame Situationen auftreten. Zum Beispiel 1) wird die Assembly NetB in einer x86-Umgebung verwendet, wo Nativex64 nicht geladen wird, oder 2) Ihr Kunde möchte eine x86-Version von App1.exe, und Sie kompilieren glücklich, da NetB als any CPU markiert ist, aber Nativex64 am Anfang des Stapels wird 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 wurde, nicht verwendet werden, da das Projekt bereits von einer Abhängigkeit zu einer Drittanbieteranwendung abhängt, die die Regel nicht befolgt hat (es ist x86, nicht AnyCPU). Daher müssen solange die Abhängigkeit besteht, alle Projektketten auf x86 und nichts anderes ausgerichtet sein.

24voto

Hans Passant Punkte 894572

Die C# DLL ist mit dem Plattformziel x86 eingerichtet

Das ist irgendwie das Problem, eine DLL kann tatsächlich nicht wählen, welches Bitness die Prozesse haben werden. Das wird vollständig vom EXE-Projekt bestimmt, das erste Assembly, das geladen wird, also ist dessen Plattformziel-Einstellung diejenige, die zählt und die Bitness für den Prozess festlegt.

Die DLLs haben keine Wahl, sie müssen mit der Prozessbitness kompatibel sein. Wenn sie es nicht sind, erhalten Sie eine große Kaboom mit einer BadImageFormatException, wenn Ihr Code versucht, sie zu verwenden.

Also eine gute Auswahl für die DLLs ist AnyCPU, damit sie auf beiden Arten funktionieren. Das macht für C# DLLs viel Sinn, sie funktionieren tatsächlich auf beiden Arten. 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 Build-System dazu bringen, Warnungen darüber zu generieren. Genau das haben Sie bekommen. Nur Warnungen, es baut trotzdem ordnungsgemäß.

Einfach das Problem ignorieren. Setzen Sie das Plattformziel des EXE-Projekts auf x86, es wird mit keiner anderen Einstellung funktionieren. Und behalten Sie einfach alle DLL-Projekte bei AnyCPU.

1 Stimmen

Also, um es klar zu machen: Ich baue nicht das EXE, ich baue eine DLL, die mit dem EXE von jemand anderem ausgeführt werden soll. Das Ändern des Zielplattforms der C# DLLs auf Any CPU beseitigt die Warnung nicht. 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 das EXE die C# DLL laden, jedoch nicht die C++ DLL, also denke ich, dass dies ein echtes Problem ist.

0 Stimmen

Verwendest du tatsächlich VS2010? Es war auch überhaupt nicht klar, dass du die C++/CLI-DLL nicht laden konntest. Was ist die Diagnose? Aktualisiere deine Fragen mit diesen wichtigen Informationen.

0 Stimmen

Hatte nicht über das Ladeproblem gepostet, weil ich nicht zu 100% sicher war, ob es damit zusammenhängt, und nach weiterem Debuggen stellte sich heraus, dass dem nicht so ist. Ich benutze VS2010. Frage aktualisiert. Entschuldigung für die Verwirrung.

9voto

yogeshwar gutte Punkte 119

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

  1. Projekt entladen

  2. Projekteigenschaften bearbeiten, d.h. .csproj

  3. Fügen Sie den folgenden Tag hinzu:

            None
  4. Projekt neu laden

5 Stimmen

Das löst das Problem nicht. Es schaltet lediglich die Warnung für das spezielle Projekt aus. In einigen Fällen halte ich es jedoch für eine gültige Lösung. Vielen Dank!

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