Jak naprawić błąd kompilacji programu Visual Studio, „niezgodność architektury procesorów”?

Jestem nowym projektantem konfiguracji w Visual Studio 2010, ale przeprowadziłem pewne badania i wciąż nie jestem w stanie rozwiązać tego problemu. Mam rozwiązanie Visual Studio z biblioteką DLL C ++ odwołującą się do biblioteki C # DLL. Biblioteka DLL C # odwołuje się do kilku innych bibliotek DLL, niektóre w ramach mojego projektu, a niektóre zewnętrzne. Gdy próbuję skompilować bibliotekę C ++ DLL, pojawia się następujące ostrzeżenie:

ostrzeżenie MSB3270: Wystąpiło niedopasowanie między architekturą procesora projektu będącego kompilacją „MSIL” a architekturą procesora odniesienia „[wewnętrzna C # dll]”, „x86”.

Mówi mi, aby przejść do programu Configuration Manager, aby wyrównać moje architektury. Biblioteka DLL C # jest skonfigurowana z platformą docelową x86. Jeśli spróbuję zmienić to na coś innego, na przykład Dowolny procesor, narzeka, ponieważ jedna z zewnętrznych bibliotek DLL , od których zależy, ma docelową platformę x86.

Kiedy patrzę na program Menedżer konfiguracji, pokazuje platformę dla mojej biblioteki C # DLL jako x86, a dla mojego projektu C ++ jako Win32. To wydaje się być właściwą konfiguracją; z pewnością nie chcę, aby projekt mojego projektu C ++ miał platformę ustawioną na x64, co jest jedyną prezentowaną opcją.

Co robię tutaj źle?

To ostrzeżenie wydaje się być wprowadzone w nowych Visual Studio 11 Beta i .NET 4.5, chociaż przypuszczam, że było to możliwe wcześniej.

Po pierwsze, to naprawdę tylko ostrzeżenie. Nie powinno to nic zaszkodzić, jeśli masz do czynienia z zależnościami x86. Microsoft próbuje cię tylko ostrzec, gdy stwierdzisz, że Twój projekt jest zgodny z „Dowolnym procesorem”, ale masz zależność od projektu lub zestawu .dll, który jest albo x86 albo x64. Ponieważ masz zależność od x86, technicznie twój projekt nie jest kompatybilny z „dowolnym procesorem”. Aby ostrzeżenie zniknęło, powinieneś zmienić projekt z „Any CPU” na „x86”. Jest to bardzo łatwe do zrobienia, oto kroki.

1. Przejdź do pozycji menu Build | Configuration Manager.
2. Znajdź swój projekt na liście, w polu Platforma powie „Any CPU”
3. Wybierz opcję „Dowolny procesor” z menu rozwijanego, a następnie wybierz <New..>
4. W tym oknie dialogowym wybierz x86 z listy rozwijanej „Nowa platforma” i upewnij się, że w rozwijanej liście „Kopiuj ustawienia z” wybrano opcję „Dowolny procesor”.
5. Kliknij OK
6. Będziesz chciał wybrać x86 dla konfiguracji debugowania i wydania.

Spowoduje to, że ostrzeżenie zniknie, a także poinformuje, że Twój zespół lub projekt nie jest już zgodny z „Dowolnym procesorem”, ale teraz jest specyficzny dla x86. Ma to również zastosowanie, jeśli budujesz 64-bitowy projekt, który jest zależny od x64; zamiast tego wybrałbyś x64.

Inna uwaga: projekty mogą być kompatybilne z „dowolnym procesorem”, zazwyczaj jeśli są projektami czysto .NET. Ten problem pojawia się tylko wtedy, gdy wprowadzisz zależność (dll innej firmy lub własny projekt zarządzany w C ++) ukierunkowany na określoną architekturę procesora.

Jest to bardzo uparte ostrzeżenie i chociaż jest to ważne ostrzeżenie, w niektórych przypadkach nie można go rozwiązać z powodu użycia komponentów innych firm i innych przyczyn. Mam podobny problem, z tym wyjątkiem, że ostrzeżenie jest spowodowane tym, że moją platformą projektów jest AnyCPU i odwołuję się do biblioteki MS zbudowanej dla AMD64. Nawiasem mówiąc, jest to w Visual Studio 2010 i wydaje się, że zostało wprowadzone przez zainstalowanie VS2012 i .Net 4.5.

Ponieważ nie mogę zmienić biblioteki MS, do której się odwołuję, i ponieważ wiem, że moje docelowe środowisko wdrażania będzie tylko 64-bitowe, mogę bezpiecznie zignorować ten problem.

Co z ostrzeżeniem? Microsoft opublikował w odpowiedzi na raport Connect, że jedną z opcji jest wyłączenie tego ostrzeżenia. Powinieneś to zrobić tylko wtedy, gdy jesteś bardzo świadomy architektury rozwiązania i w pełni rozumiesz cel wdrożenia i wiesz, że tak naprawdę nie jest to problem poza środowiskiem programistycznym.

Możesz edytować plik projektu i dodać tę grupę właściwości oraz ustawienie, aby wyłączyć ostrzeżenie:

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

Dobrą zasadą są „otwarte biblioteki DLL, zamknięte pliki EXE”, to znaczy:

• EXE jest ukierunkowany na system operacyjny, określając x86 lub x64.
• Biblioteki DLL pozostają otwarte (tj. AnyCPU), dzięki czemu mogą być tworzone w ramach procesu 32-bitowego lub 64-bitowego.

Gdy budujesz plik EXE jako AnyCPU, wszystko, co robisz, to odraczanie decyzji o tym, jaka bitowość procesu ma być używana w systemie operacyjnym, co JIT będzie odpowiadało JEI. Oznacza to, że system operacyjny x64 utworzy proces 64-bitowy, system operacyjny x86 utworzy proces 32-bitowy.

Budowanie bibliotek DLL jako AnyCPU czyni je kompatybilnymi z dowolnym procesem.

Więcej informacji na temat subtelności ładowania zestawu można znaleźć tutaj . Streszczenie brzmi mniej więcej tak:

• AnyCPU - ładuje się jako zestaw x64 lub x86, w zależności od procesu wywoływania
• x86 - ładuje się jako zespół x86; nie ładuje się z procesu x64
• x64 - ładuje się jako zespół x64; nie ładuje się z procesu x86

Biblioteka DLL C # jest skonfigurowana z platformą docelową x86

Co jest tego rodzaju problemem, biblioteka DLL tak naprawdę nie może wybrać bitowości procesu. Jest to całkowicie zdeterminowane przez projekt EXE, jest to pierwszy zestaw, który jest ładowany, więc jego ustawienie docelowe platformy jest tym, które liczy i ustawia bitowość procesu.

Biblioteki DLL nie mają wyboru, muszą być zgodne z bitami procesu. Jeśli nie są, dostaniesz duży Kaboom z BadImageFormatException, gdy twój kod spróbuje ich użyć.

Tak więc dobrym wyborem dla bibliotek DLL jest AnyCPU, więc działają one w obie strony. Ma to sens w przypadku bibliotek C # DLL, które działają w obie strony. Ale oczywiście, nie twoja biblioteka DLL trybu mieszanego C ++ / CLI, zawiera niezarządzany kod, który może działać dobrze tylko wtedy, gdy proces działa w trybie 32-bitowym. Państwo może uzyskać kompilacji systemu do generowania ostrzeżeń o tym. Właśnie to masz. Tylko ostrzeżenia, nadal działa poprawnie.

Po prostu rozwiąż problem. Ustaw docelową platformę projektu EXE na x86, nie będzie działać z żadnym innym ustawieniem. I po prostu zachowaj wszystkie projekty DLL w AnyCPU.

Otrzymywałem to samo ostrzeżenie, co ja:

1. rozładuj projekt
2. edytuj właściwości projektu, tj. .csproj

3. dodaj następujący tag:

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

4. Załaduj ponownie projekt

Miałem dzisiaj ten problem i po prostu przeglądanie konfiguracji budynku w Visual Studio nie pomogło, ponieważ pokazało Dowolny procesor zarówno dla projektu, który nie był budowany, jak i projektu, do którego się odwołuje.

Potem przejrzałem csproj odnośnego projektu i znalazłem to:

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

Jakoś ten PlatformTarget został dodany w trakcie zmiany konfiguracji i IDE go nie widział.

Usunięcie tej linii z odnośnego projektu rozwiązało mój problem.

Jeśli twoja biblioteka DLL C # ma zależności oparte na x86, to sama biblioteka DLL będzie musiała być x86. Naprawdę nie widzę sposobu na obejście tego. VS skarży się na zmianę go na (na przykład) x64, ponieważ 64-bitowy plik wykonywalny nie może załadować bibliotek 32-bitowych.

Jestem trochę zdezorientowany co do konfiguracji projektu C ++. Komunikat ostrzegawczy, który został dostarczony dla kompilacji, sugeruje, że był on ukierunkowany na AnyCPU, ponieważ zgłosił platformę, na którą był atakowany, [MSIL], ale wskazałeś, że konfiguracja projektu była w rzeczywistości Win32. Natywna aplikacja Win32 nie powinna uwzględniać MSIL - chociaż prawdopodobnie musiałaby mieć włączoną obsługę CLR, jeśli wchodzi w interakcję z biblioteką C #. Myślę więc, że istnieje kilka luk po stronie informacyjnej.

Czy mogę z szacunkiem poprosić o przejrzenie i opublikowanie nieco więcej szczegółów na temat dokładnej konfiguracji projektów i ich wzajemnych powiązań? Z przyjemnością pomożemy dalej, jeśli to możliwe.

Oprócz David Sacks odpowiedź, może być konieczne, aby przejść do Buildzakładki z Project Propertiesoraz zestaw Platform Targetdo x86do projektu, który daje Ci te ostrzeżenia. Chociaż można się tego spodziewać, to ustawienie nie wydaje się być idealnie zsynchronizowane z ustawieniem w menedżerze konfiguracji.

W przypadku projektów w C #, cel x86 robi to, na co wygląda. Mówi, że ten zestaw obsługuje tylko architektury x86. Podobnie dla x64. Każdy procesor z drugiej strony mówi, że nie dbam o to, którą architekturę, obsługuję oba. Zatem następne 2 pytania to (1) jaka jest konfiguracja pliku wykonywalnego, który korzysta z tych bibliotek DLL? i (2) jaka jest bitowośćtwojego systemu operacyjnego / komputera? Powodem, dla którego pytam, jest to, że jeśli twój plik wykonywalny jest skompilowany do działania w trybie 64-bitowym, POTRZEBUJE, aby wszystkie zależności mogły działać również w trybie 64-bitowym. Twój Dowolny zestaw procesora powinien być możliwy do załadowania, ale być może odwołuje się on do innej zależności, która może działać tylko w konfiguracji x86. Sprawdź wszystkie zależności i zależności zależności, aby upewnić się, że wszystko to „Dowolny procesor” lub „x64”, jeśli planujesz uruchomić plik wykonywalny w trybie 64-bitowym. W przeciwnym razie będziesz mieć problemy.

Pod wieloma względami program Visual Studio nie ułatwia kompilacji mieszanki dowolnego procesora i różnych zestawów zależnych od architektury. Jest to wykonalne, ale często wymaga, aby zestaw, który w innym przypadku byłby „dowolnym procesorem”, musiałby zostać skompilowany osobno dla x86 i x64, ponieważ gdzieś zależność zależności ma dwie wersje.

Miałem wcześniej podobny problem, szczególnie podczas dodawania testowego rozwiązania do istniejącego rozwiązania x64, takiego jak SharePoint. W moim przypadku wydaje się, że ma to związek z tym, że niektóre szablony projektów są domyślnie dodawane jako określone platformy.

Oto rozwiązanie, które często dla mnie działa: ustaw wszystko na odpowiednią platformę w programie Configuration Manager (aktywne menu rozwijane konfiguracji, mówi Debugowanie normalne, jest dobrym sposobem, aby się do tego dostać) i platformę projektu (we właściwościach projektu), a następnie buduj, a następnie ustaw wszystko z powrotem na AnyCPU. Czasami muszę usunąć i ponownie dodać niektóre zależności (biblioteki DLL we właściwościach każdego projektu), a czasem „Uruchom testy w procesie 32-bitowym lub 64-bitowym” (dwukrotnie kliknij Local.testsettings i przejdź do Hosts).

Wydaje mi się, że to tylko ustawienie czegoś, a potem cofnięcie, ale prawdopodobnie za kulisami dzieje się coś więcej, czego nie widzę. W przeszłości działało to dla mnie dość konsekwentnie.

W moim projekcie muszę mieć możliwość kompilacji zarówno na x86, jak i x64. Problem polega na tym, że ilekroć dodajesz referencje podczas korzystania z jednego, wtedy narzeka, gdy budujesz drugi.

Moim rozwiązaniem jest ręczna edycja plików * .csproj, aby takie linie:

<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"/>

zmień się na to:

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

Miałem podobny problem, który został spowodowany przez MS UNIT Test DLL. Moja aplikacja WPF została skompilowana jako x86, ale testowa jednostka DLL (do pliku EXE) jako „Dowolny procesor”. Zmieniłem bibliotekę DLL testu jednostkowego, aby była kompilowana dla x86 (to samo, co EXE) i została ponownie uruchomiona.

Możesz również otrzymać to ostrzeżenie dla zestawów MS Fakes, które nie jest tak łatwe do rozwiązania, ponieważ f.csproj jest budowany na polecenie. Na szczęście xml Fakes pozwala tam go dodać .

Powinien istnieć sposób na utworzenie pliku .NET EXE / DLL AnyCPU i dowolnych niezarządzanych bibliotek DLL zależnych od kompilacji zarówno z x86, jak i x64, obie w pakiecie być może z różnymi nazwami plików, a następnie moduł .NET dynamicznie ładuje poprawną na podstawie jej środowiska uruchomieniowego architektura procesora. To by uczyniło AnyCPU potężnym. Jeśli biblioteka DLL C ++ obsługuje tylko x86 lub x64, AnyCPU jest oczywiście bezcelowe. Ale łączenie obu pomysłów, które muszę jeszcze wdrożyć, ponieważ menedżer konfiguracji nie zapewnia nawet możliwości dwukrotnego zbudowania tego samego projektu z inną konfiguracją / platformą dla wielokrotnego łączenia, umożliwiając dowolną konfigurację lub nawet inne koncepcje, takie jak dowolna konfiguracja.

Miałem bardzo podobne ostrzeżenie w mojej wersji. Moje projekty były ustawione na .NET 4.5, na serwerze kompilacji zainstalowano zestaw Windows 8.1 SDK (dla .NET 4.5.1). Po zaktualizowaniu moich projektów do systemu .NET 4.5.1 (nie było dla mnie problemem, dotyczyło zupełnie nowej aplikacji), nie otrzymałem już ostrzeżenia ...

To ostrzeżenie rozwiązałem, zmieniając „Menedżera konfiguracji” na wersję (Mixed Plataform).

To ostrzeżenie pojawiło się w programie Visual Studio 2012 podczas kompilacji zadania skryptu potokowego SSIS programu SQL Server 2012 z dodatkiem SP1 - do momentu zainstalowania dodatku SP2 dla programu SQL Server 2012.

Miałem ten sam problem z otwieraniem połączenia SQLite i naprawiłem to za pomocą Nuget i instalacji komponentu używanego w projekcie (SQLite)! spróbuj zainstalować swój komponent w ten sposób i sprawdź wynik

Użyj https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build#directorybuildprops-example :

• dodaj plik Directory.Build.props do folderu rozwiązania
• wklej to w to:

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