„Podjęto próbę załadowania programu o niepoprawnym formacie”, nawet jeśli platformy są takie same

Wywołuję funkcje z 32-bitowej niezarządzanej biblioteki DLL w systemie 64-bitowym. Dostaję to:

BadImageFormatException: Podjęto próbę załadowania programu o niepoprawnym formacie. (Wyjątek od HRESULT: 0x8007000B)

Na początku moje projekty były ustawione na platformę Any CPU, więc zmieniłem je oba na x86, ale ten błąd nadal występuje. To naprawdę jedyna poprawka, jaką znam na to.

Biblioteki DLL nie są uszkodzone ani nic, ponieważ mogę ich używać z innymi programami (do których nie mam źródła). Pomyślałem, że może nie chodziło o znalezienie zależności, ale sprawdziłem i wszyscy tam są. Plus, czy to nie rzuciłoby DllNotFoundExceptionw tym przypadku?

Co jeszcze mogę zrobić? I zanim powiesz „Zamiast tego użyj 64-bitowej niezarządzanej biblioteki DLL”, zwróć uwagę, że nie ma takiej. ;)

Jeśli spróbujesz uruchomić 32-bitowe aplikacje na IIS 7 (i / lub 64-bitowym komputerze z systemem operacyjnym), pojawi się ten sam błąd. Tak więc w IIS 7 kliknij prawym przyciskiem myszy pulę aplikacji i przejdź do „ustawień zaawansowanych” i zmień „Włącz aplikacje 32-bitowe” na „PRAWDA”.

Uruchom ponownie witrynę i powinna działać.

W jakiś sposób pole wyboru Kompilacja w menedżerze konfiguracji zostało odznaczone dla mojego pliku wykonywalnego, więc nadal działało ze starą kompilacją Any CPU. Po tym, jak to naprawiłem, Visual Studio narzekało, że nie może debugować zestawu, ale zostało to naprawione przy ponownym uruchomieniu.

W Visual Studio kliknij projekt prawym przyciskiem myszy -> W lewym okienku kliknij kartę Kompilacja ,

w obszarze Platform Target wybierz x86 (lub bardziej ogólnie architekturę pasującą do biblioteki, do której się łączysz)

Mam nadzieję, że to komuś pomoże! :)

Właśnie miałem ten problem. Wypróbowałem wszystkie sugestie tutaj, ale nie pomogły.

Znalazłem inną rzecz, by to naprawić. W Visual Studio kliknij projekt prawym przyciskiem myszy i otwórz „Właściwości”. Kliknij kartę „Kompiluj” (lub „Kompiluj”), a następnie kliknij „Zaawansowane opcje kompilacji” u dołu.

Sprawdź listę rozwijaną „Docelowy procesor”. Powinien pasować do budowanej platformy. To znaczy, jeśli budujesz „Dowolny procesor”, to „Docelowy procesor” powinien powiedzieć „Dowolny procesor”. Przejdź przez wszystkie swoje platformy, aktywując je i sprawdź to ustawienie.

Jeśli napotkasz ten błąd po kliknięciu przycisku zielonej strzałki, aby uruchomić aplikację, ale nadal chcesz uruchomić aplikację w wersji 64-bitowej. Możesz to zrobić w VS 2013, 2015, 2017 i 2019

Przejdź do: Narzędzia> Opcje> Projekty i rozwiązania> Projekty internetowe> Użyj 64-bitowej wersji IIS Express

Jeśli używasz dowolnego procesora , możesz napotkać ten problem, jeśli zaznaczona jest opcja Preferuj 32-bit :

Usuń zaznaczenie tej opcji na karcie Kompilacja właściwości projektu !

Trochę nie na temat tego postu, ale poszukiwanie tego komunikatu o błędzie mnie tu przywiodło.

Jeśli budujesz za pośrednictwem systemu zespołu i pojawia się ten błąd, karta procesu definicji kompilacji ma ustawienie „Platforma MSBuild”. Jeśli ta opcja jest ustawiona na „Auto”, może wystąpić ten problem. Zmiana na „X86” może również rozwiązać błąd.

W moim przypadku korzystałem z natywnej biblioteki DLL w języku C #. Ta biblioteka DLL zależała od kilku innych brakujących bibliotek DLL. Po dodaniu innych bibliotek DLL wszystko działało.

Opierając się na odpowiedzi @paibamboo

Powiedział: Przejdź do: Narzędzia> Opcje> Projekty i rozwiązania> Projekty internetowe> Użyj 64-bitowej wersji IIS Express

Mój współpracownik zaznaczył to pole (wyraźnie go szukał), ale zapytał o komunikat o błędzie. Po kilku godzinach odznaczył pole i ponownie je zaznaczył. Lo i patrz: kod działał teraz z sukcesem.

Wygląda na to, że istnieją dwa miejsca, w których zapisano stan tego urządzenia, które zostały zsynchronizowane. Odznaczenie i ponowne sprawdzenie zsynchronizowało go ponownie.

Pytanie dla bardziej kompetentnych użytkowników: czy w zeszłym tygodniu pojawiła się aktualizacja lub coś (dla VS 2015), która zsynchronizowała stany?

Zobacz także tę odpowiedź , która rozwiązała dla mnie ten sam problem.

Wysłany przez Luis Mack w dniu 2010-05-12 o 08:50 Znalazłem ten sam problem, tylko w przypadku konkretnego projektu podczas kompilacji na komputerze 64-bitowym. Rozwiązaniem, które SEEMS działa, jest ręczna zmiana jednego znaku w strumieniu obrazu za każdym razem, gdy kontrolka użytkownika lub formularz są edytowane w projektancie

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w

Zmień na

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w

To jest 00LjAuMC4w z powrotem do 0yLjAuMC4w na końcu linii (00 z powrotem do 0y)

W moim przypadku używam małego pliku .exe, który ponownie ładuje przywoływane biblioteki DLL za pomocą Reflection. Wykonuję więc następujące kroki, które oszczędzają mi dzień:

Z właściwości projektu w eksploratorze rozwiązań na karcie kompilacji wybieram docelową platformę x86

W moim przypadku przeprowadzałem testy przez MSTest i dowiedziałem się, że wdrażam zarówno 32-bitową, jak i 64-bitową bibliotekę DLL w katalogu testowym. Program faworyzował 64-bitową bibliotekę DLL i powodował jej awarię.

TL; DR Upewnij się, że wdrażasz tylko 32-bitowe biblioteki DLL do testów.

Mieliśmy podobny problem i udało nam się go naprawić, ustawiając docelową platformę na x86.

Rozwiązałem ten problem w sposób „Windows”. Po sprawdzeniu wszystkich ustawień, wyczyszczeniu rozwiązania i przebudowaniu go, po prostu zamykam rozwiązanie i ponownie je otwieram. Potem działało, więc VS prawdopodobnie nie pozbył się niektórych rzeczy podczas czyszczenia. Kiedy rozwiązania logiczne nie działają, zwykle przechodzę na rozwiązania nielogiczne (lub pozornie nielogiczne). Windows mnie nie zawodzi. :)

Udało mi się rozwiązać ten problem, dopasowując moją wersję kompilacji do wersji .NET na serwerze.

Dwukrotnie kliknąłem plik .exe, aby zobaczyć, co się stanie, i kazałem zainstalować 4.5 ....

Więc obniżyłem do 4.0 i zadziałało!

Upewnij się więc, że Twoje wersje pasują. Działa poprawnie na moim dev dev box, ale serwer miał starszą wersję .NET.

W moim przypadku była to nieprawidłowa zawartość pliku. Biblioteka DLL została pobrana z Internetu, ale zawartość biblioteki DLL to strona HTML: D Spróbuj sprawdzić, czy jest to plik binarny, czy wygląda na poprawną bibliotekę DLL :)

Ten sam problem występował w rdzeniu .NET. Rozwiązaniem było pobranie 32-bitowego środowiska uruchomieniowego .netcore i posiadanie celu projektux86

W swoim csprojpliku dodaj

  <PropertyGroup>
    <PlatformTarget>x86</PlatformTarget>  
  </PropertyGroup>

  <PropertyGroup>
    <RunCommand Condition="'$(PlatformTarget)' == 'x86'">$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>    
  </PropertyGroup>

To było używane na komputerze z systemem Windows, trzeba będzie dostosować ścieżki i tak dla Linux / OSX

Jeśli importujesz niezarządzaną bibliotekę DLL, użyj

CallingConvention = CallingConvention.Cdecl 

w metodzie importowania DLL.

1: Przejdź do: Narzędzia> Opcje> Projekty i rozwiązania> Projekty internetowe> Użyj 64-bitowej wersji IIS Express 2: zmień poniższe ustawienie dla projektu usługi internetowej.