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

458

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?

Paul Eastlund
quelle
Was ist die Beschwerde speziell, wenn Sie sie auf eine beliebige CPU ändern?
Lordcheeto
2
Ich habe nicht genügend Informationen, um einen informierten Vorschlag zu machen, aber klicken Sie mit der rechten Maustaste auf Ihre Lösung -> Projekterstellungsreihenfolge und stellen Sie sicher, dass Ihr C # -Projekt vor dem C ++ - Projekt erstellt wird. Wenn dies nicht der Fall ist, wechseln Sie zur Registerkarte Abhängigkeiten und teilen Sie VS mit, dass das C ++ - Projekt vom C # -Projekt abhängt.
Lordcheeto
2
Visual Studio ist wieder Mist. Die Plattform oben auf meinem Bildschirm zeigt x64 an, aber die Warnung besagt, dass das zu erstellende Projekt "MSIL" ist. Visual Studio sagt mir also, dass es ein Missverhältnis zwischen Äpfeln und Orangen gibt, wenn ich keine Äpfel verwende. Können wir es in Visual Stupido umbenennen?
Paul McCarthy
Für mich ist dies ein Fehler in Visual Studio. Ich wähle x64 als Plattformziel aus und es sagt mir, dass das Projekt für MSIL erstellt wird.
Paul McCarthy
Die kurze Antwort lautet: Wenn Ihr Projekt Abhängigkeiten von x86 oder x64 aufweist, können Sie keine CPU verwenden (dies gilt nur für reine .NET-Anwendungen). Sie müssen also entweder für x64 oder x32 bauen, nicht für irgendeine CPU. Dies ist aus Daves Antwort abgeleitet
zar

Antworten:

513

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.

David Sacks
quelle
3
Ich habe gerade das RTW von Visual Studio 2012 installiert und eine bereits vorhandene 2010-Lösung geöffnet und die gleiche Warnung angezeigt, sodass sie im RTW noch vorhanden ist.
Tod Thomson
4
Abgesehen davon denke ich, dass Davids Antwort richtig ist. Diese Warnung lässt Sie wissen, dass Ihre App wirklich nicht "AnyCPU" ist, sodass Sie auf Probleme stoßen, wenn Sie sie schließlich auf der falschen Architektur bereitstellen.
Tod Thomson
6
Es kann sehr gut etwas verletzen. Eine beliebige CPU-Exe wird unter einem 64-Bit-Betriebssystem als x64 geladen und kann keine x86-DLLs laden. Wenn Sie also von einer bestimmten Plattform abhängig sind, sollten Sie Ihre Plattform wirklich richtig einstellen.
Yaur
1
Das Build-Menü scheint in VS C # 2010 Express zu fehlen. Wie komme ich dazu? Ich wünschte, sie würden die Dinge nicht verstecken.
Xonatron
1
Ich habe
144

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>
Gio Palacino
quelle
1
Der einzige andere offizielle MS-Verweis auf diese Lösung, den ich gesehen habe, befindet sich in der Readme-Datei von Microsoft .NET Framework 4.5 RC . Seltsamerweise wurde es aus der RTM Readme-Datei entfernt.
JohnC
4
Dies funktioniert, jedoch nicht für eine Variation der Warnung: "Referenzierte Assembly ... zielt auf einen anderen Prozessor als die Anwendung ab". Es wäre toll, wenn es eine ähnliche Einstellung für diese Warnung gäbe?
Jimmy
6
"Meine Projektplattform ist AnyCPU und ich verweise auf eine für AMD64 erstellte MS-Bibliothek" ... Das ist FALSCH. Da Ihre Zielbereitstellung immer 64-Bit ist, können Sie Ihre Plattform auf x64 einstellen. Dies führt zu einem angemesseneren Fehler, wenn Ihre 64-Bit-Annahme jemals verletzt wird, und verhindert auch die Warnung.
Ben Voigt
2
@BenVoigt ist theoretisch eine großartige Idee, aber VS als x86-Prozess benötigt x86-Steuerelemente, um Dinge wie den Windows Forms Designer auszuführen, selbst wenn Ihre Anwendung immer nur 64-Bit sein wird. Es ist ein gültiger, aber unglücklicher Grund, einen falschen Build "Any CPU" zu verwenden.
jrh
1
@jrh: Fügen Sie dann die GUI in ein DLL-Projekt ein und erstellen Sie diese als AnyCPU. Die EXE-Datei muss mit der richtigen Architektur gekennzeichnet sein, damit sie den nativen Abhängigkeiten entspricht. Die ordnungsgemäße Trennung der GUI von der Logik ist ein langer Weg (obwohl sie immer noch ihre Grenzen hat, z. B. wenn der native Code einen Teil der GUI rendert, ist die Designerunterstützung jedoch eine verlorene Ursache, es sei denn, Sie erstellen das gesamte Projekt für beide x86 und x64)
Ben Voigt
61

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
Gustavo Mori
quelle
4
Diese Regel macht für mich Sinn. Beachten Sie jedoch die folgende Situation: Native.dll (x64), die von NetA.dll (Beliebige CPU) verwendet wird. Hier gibt es kein wirkliches Problem, aber das Kompilieren von NetA.dll gibt mir die Warnung. OK, da diese Assembly direkt von Native.dll abhängt, könnte ich sie auch als x64 markieren. Aber dann beschwert sich das Kompilieren von NetB.dll. Ich möchte NetB.dll als "Beliebige CPU" beibehalten, da es sich um eine allgemeine Assembly handelt, die in einer anderen Pure-Dot-Net-Anwendung verwendet wird. Ich komme zu dem Schluss, dass meine einzige Möglichkeit darin besteht, die Warnung zu unterdrücken / zu ignorieren. Ja?
Steve Robbins
2
Aufgrund der Abhängigkeit von Native.dll ist Ihre gesamte App- / Assembly-Linie jetzt x64, unabhängig davon, ob Sie die Warnung unterdrücken oder nicht. Während die Unterdrückung in Ihrem Szenario funktioniert, können in Zukunft seltsame Situationen auftreten. Beispiel: 1) Assembly NetB wird 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 problemlos, da NetB als jede CPU markiert ist. Nativex64 an der Spitze des Stapels wird nicht geladen
Gustavo Mori
Die Regel von Gustavo ist zwar ein gutes Prinzip, kann jedoch nicht für das in dieser Frage gestellte spezifische Problem verwendet werden, da das Projekt bereits von einer Assembly eines Drittanbieters abhängig ist, die der Regel nicht folgt (es ist x86, nicht AnyCPU). Solange also die Abhängigkeit besteht, muss die gesamte Projektkette auf x86 und nichts anderes abzielen.
David Burg
23

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.

Hans Passant
quelle
1
Um ganz klar zu sein: Ich erstelle nicht die EXE-Datei, sondern eine DLL, die mit der EXE-Datei eines anderen ausgeführt werden soll. Durch Ändern des Plattformziels der C # -DLLs in eine beliebige CPU wird die Warnung nicht entfernt. 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, aber nicht die C ++ - DLL Ich denke, das ist ein echtes Problem.
Paul Eastlund
Verwenden 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 wichtigen Informationen.
Hans Passant
Hatte nicht über den Lastfehler geschrieben, weil ich nicht 100% sicher war, dass er verbunden war, und beim weiteren Debuggen stellte sich heraus, dass dies nicht der Fall war. Ich benutze VS2010. Der Fragentext wurde aktualisiert. Sehr leid für die Verwirrung
Paul Eastlund
1
Sie haben keine Fehler oder Ausnahmen beim Laden der DLL dokumentiert. Ich kann dir nicht helfen, wenn du mir nicht sagst, was du weißt. Viel Glück damit.
Hans Passant
5

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

Yogeshwar Gutte
quelle
2
Dies löst das Problem nicht. Es wird lediglich die Warnung für das jeweilige Projekt deaktiviert. Aber in einigen Fällen finde ich es eine gültige Lösung. Vielen Dank!
Winziger
4

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.

JBourne
quelle
Ich habe einen ganzen Tag gebraucht, um das herauszufinden. Vielen Dank! :)
SohamC
3

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.

David W.
quelle
3

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.

Dave Cousineau
quelle
2

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.

Jonathan DeCarlo
quelle
Ist die Konfiguration der ausführbaren Datei relevant, da beim Versuch, die DLLs zu erstellen, ein Fehler auftritt? (Es ist allerdings x86.) Mein Computer ist x64.
Paul Eastlund
2
Es ist die ausführbare Datei, die bestimmt, welche Bitness verwendet wird. Wenn die ausführbare Datei als x64 ausgeführt wird, muss alles, was sie (direkt oder indirekt) lädt, x64 oder eine beliebige CPU sein. Wenn die ausführbare Datei als x86 ausgeführt wird, muss alles, was (direkt oder indirekt) geladen wird, x86 oder eine beliebige CPU sein.
Jonathan DeCarlo
1

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.

ssamuel
quelle
1

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"/>
Thick_propheT
quelle
1

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.

user1257110
quelle
0

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.

Gregory Morse
quelle
2
Willkommen bei Stackoverflow! Können Sie versuchen, diese Antwort ein wenig zu fokussieren / neu zu formatieren?
Corley Brigman
Das klingt so, als würde es eine gute Frage stellen, oder einen Blog-Beitrag oder eine Feature-Anfrage auf Connect ... es beantwortet diese Frage nicht wirklich.
Ben Voigt
0

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 ...

NicoCV
quelle
0

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

Edu Pelais
quelle
0

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.

cdonner
quelle
0

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

StudioX
quelle