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


458

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?


Na czym polega skarga, kiedy zmienisz ją na dowolny procesor?
lordcheeto

2
Nie mam wystarczających informacji, aby podać świadomą sugestię, ale kliknij prawym przyciskiem myszy swoje rozwiązanie -> Kolejność kompilacji projektu i upewnij się, że projekt C # jest budowany przed projektem C ++. Jeśli nie, przejdź do zakładki Zależności i powiadom VS, że projekt C ++ zależy od projektu C #.
lordcheeto

2
Visual Studio znów jest do bani. Platforma na górze ekranu wyświetla x64, ale ostrzeżenie mówi, że budowany projekt to „MSIL”. Więc Visual Studio mówi mi, że istnieje niedopasowanie między jabłkami i pomarańczami, kiedy nie używam jabłek. Czy możemy zmienić nazwę na Visual Stupido?
Paul McCarthy

Według mnie jest to błąd w Visual Studio. Wybieram x64 jako platformę docelową i mówi mi to, że projekt jest tworzony dla MSIL.
Paul McCarthy

Krótka odpowiedź brzmi: jeśli twój projekt jest zależny od x86 lub x64, nie możesz użyć Dowolnego CPU (tylko dla aplikacji .NET). Więc musisz budować dla x64 lub x32, a nie dla dowolnego procesora. Wywodzi się to z odpowiedzi
zar

Odpowiedzi:


512

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.


3
Właśnie zainstalowałem RTW Visual Studio 2012 i otworzyłem istniejące wcześniej rozwiązanie 2010 i zacząłem widzieć to samo ostrzeżenie, więc jest to coś, co nadal istnieje w RTW.
Tod Thomson,

4
Biorąc to pod uwagę, uważam, że odpowiedź Davida jest prawidłowa, to ostrzeżenie informuje, że twoja aplikacja tak naprawdę nie jest „AnyCPU”, więc napotkasz problemy, gdy ostatecznie wdrożysz ją w niewłaściwej architekturze.
Tod Thomson,

6
Bardzo dobrze MOŻE coś zranić. Dowolny plik exe procesora zostanie załadowany jako x64 w 64-bitowym systemie operacyjnym i nie będzie mógł załadować bibliotek dll x86. Więc jeśli masz zależność od konkretnej platformy, naprawdę powinieneś poprawnie ustawić platformę.
Yaur

1
Menu kompilacji wydaje się brakować w VS C # 2010 Express. Jak się do tego dostać? Chciałbym, żeby nie ukrywali rzeczy.
Xonatron,

1
Właśnie dowiedziałem się, jak włączyć menu kompilacji w programie Visual Studio 2010 Express: menu Narzędzia -> Ustawienia -> wybierz „Ustawienia eksperta”
Xonatron,

144

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>

1
Jedyne inne oficjalne odniesienie MS do tego rozwiązania, które widziałem, znajduje się w pliku Readme programu Microsoft .NET Framework 4.5 RC . O dziwo został usunięty z pliku Readme RTM.
JohnC

4
Działa to, ale nie dla odmiany ostrzeżenia: „Referenced assembly… targetuje inny procesor niż aplikacja”. Byłoby wspaniale, gdyby istniało podobne ustawienie dla tego ostrzeżenia?
Jimmy

6
„moją platformą projektów jest AnyCPU i mam na myśli bibliotekę MS zbudowaną dla AMD64” ... To jest NIEPRAWIDŁOWE. Ponieważ docelowe wdrożenie jest zawsze 64-bitowe, możesz ustawić platformę na x64, co sprawia, że ​​błąd jest bardziej odpowiedni, jeśli Twoje 64-bitowe założenie zostanie kiedykolwiek naruszone, a także zapobiega ostrzeżeniu.
Ben Voigt

2
@BenVoigt to świetny pomysł w teorii, ale VS jako proces x86 wymaga x86 kompilacji formantów do uruchamiania rzeczy takich jak Windows Forms Designer, nawet jeśli twoja aplikacja będzie tylko 64-bitowa. Jest to prawidłowy, ale niefortunny powód, aby używać fałszywej kompilacji „Any CPU”.
jrh

1
@jrh: Następnie umieścić GUI w projekcie DLL i budować , że jako AnyCPU. EXE musi być oznaczony odpowiednią architekturą, aby pasowała do natywnych zależności. Właściwe oddzielenie GUI od logiki ma długą drogę (chociaż nadal ma swoje ograniczenia, na przykład gdy kod macierzysty renderuje część GUI, ale wsparcie projektanta jest straconą przyczyną, chyba że wykonasz kompilacje całego projektu dla obu x86 i x64)
Ben Voigt

61

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

4
Ta zasada ma dla mnie sens. Ale rozważ następującą sytuację: Native.dll (x64) używany przez NetA.dll (dowolny procesor) używany przez NetB.dll (dowolny procesor) używany przez App1.exe (x64). Nie ma tutaj prawdziwego problemu, ale kompilacja NetA.dll daje mi ostrzeżenie. OK, ponieważ ten zespół zależy bezpośrednio od Native.dll, mógłbym oznaczyć go również jako x64. Ale potem kompilacja NetB.dll narzeka. Chcę zachować NetB.dll jako „Dowolny procesor”, ponieważ jest to wspólny zestaw używany w innej aplikacji wykorzystującej czystą kropkę. Doszedłem do wniosku, że moją jedyną opcją jest pomijanie / ignorowanie ostrzeżenia. Tak?
Steve Robbins

2
Z powodu zależności od pliku Native.dll cała linia aplikacji / zestawu ma teraz x64, niezależnie od tego, czy zignorujesz ostrzeżenie, czy nie. Podczas gdy eliminacja działa w twoim scenariuszu, w przyszłości mogą pojawić się dziwne sytuacje. Na przykład: 1) zestaw NetB jest używany w środowisku x86, w którym Nativex64 się nie ładuje, lub 2) klient chce wersji App1.exe x86 i kompilujesz się szczęśliwie, ponieważ NetB jest oznaczony jako dowolny procesor, ale ponownie, Nativex64 na górze stosu nie zostanie załadowany
Gustavo Mori

Chociaż reguła Gustavo jest dobrą zasadą, nie można jej użyć do konkretnego problemu zadanego w tym pytaniu, ponieważ projekt jest już zależny od zestawu zewnętrznego, który nie przestrzegał reguły (to x86, a nie AnyCPU). Dlatego tak długo, jak istnieje zależność, cały łańcuch projektów musi być ukierunkowany na x86 i nic więcej.
David Burg

23

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.


1
Tak więc, dla jasności: nie buduję EXE, buduję bibliotekę DLL, która ma być uruchamiana z cudzym EXE. Zmiana docelowej platformy bibliotek DLL C # na dowolny procesor nie eliminuje ostrzeżenia. Zastanawiam się, czy jest to przypadek connect.microsoft.com/VisualStudio/feedback/details/728901/... - Zignorowałbym to ostrzeżenie, ale w rzeczywistości EXE jest w stanie załadować bibliotekę C # DLL, ale nie bibliotekę DLL C ++ więc myślę, że to prawdziwy problem.
Paul Eastlund,

Czy faktycznie używasz VS2010? Nie było też wcale jasne, że nie można załadować biblioteki DLL C ++ / CLI. Co to jest diagnostyka? Zaktualizuj swoje pytania za pomocą tych niezbędnych informacji.
Hans Passant

Nie napisałem o awarii ładowania, ponieważ nie byłem w 100% pewien, że został podłączony, a po dalszym debugowaniu okazuje się, że nie. Używam VS2010. Zaktualizowany tekst pytania. Bardzo przepraszam za zamieszanie
Paul Eastlund

1
Nie udokumentowano żadnego błędu ani wyjątku związanego z ładowaniem biblioteki DLL. Nie mogę ci pomóc, jeśli nie powiesz mi tego, co wiesz. Powodzenia z tym.
Hans Passant

5

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


2
To nie rozwiązuje problemu. Wyłącza tylko ostrzeżenie dla konkretnego projektu. Ale w niektórych przypadkach uważam to za prawidłowe rozwiązanie. Dzięki!
Tiny

4

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.


Rozpracowanie tego zajęło mi cały dzień. Wielkie dzięki! :)
SohamC

3

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.


3

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.


2

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.


Czy konfiguracja pliku wykonywalnego jest istotna, ponieważ dostaję błąd podczas próby zbudowania bibliotek DLL? (Jest to x86.) Mój komputer to x64.
Paul Eastlund,

2
To plik wykonywalny określa, jaka bitowość zostanie użyta. Jeśli plik wykonywalny działa jako x64, to wszystko, co ładuje (bezpośrednio lub pośrednio), musi mieć format x64 lub dowolny procesor. Jeśli plik wykonywalny działa jako x86, wszystko jest ładowane (bezpośrednio lub pośrednio) musi być x86 lub dowolny procesor.
Jonathan DeCarlo

1

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.


1

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

1

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.



0

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.


2
Witamy w Stackoverflow! czy możesz spróbować trochę skoncentrować / sformatować tę odpowiedź?
Corley Brigman

Wygląda na to, że byłoby to dobre pytanie, post na blogu lub prośba o dodanie funkcji w Connect ... tak naprawdę nie odpowiada na to pytanie.
Ben Voigt

0

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


0

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


0

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.


0

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


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.