Mam DLL (FreeType), który jest z pewnością 32-bitowy (nagłówek: IMAGE_FILE_MACHINE_I386).BadImageFormatException podczas ładowania 32-bitowej biblioteki DLL, docelowym jest x86
Chcę użyć go z kodu C#, używając DllImport.
Celem mojej aplikacji jest x86, IntPtr.Size to 4, proces jest 32-bitowy.
Ale otrzymuję BadImageFormatException (wyjątek od HRESULT: 0x8007000B). Co może być nie tak?
Oczywiście używam 64-bitowego systemu Windows 7.
Z tego co rozumiem, zespół zbudowany specjalnie dla x86 i działa w systemie operacyjnym 64-bitowym może tylko biblioteki obciążenia zbudowany dla x86 lub BadImageFormatException będzie rzucony. W 64-bitowym systemie operacyjnym zestaw zbudowany dla dowolnego procesora lub procesora x64 wygeneruje ten sam wyjątek podczas próby załadowania biblioteki x86.
Zakładając, że nie dzieje się nic niesamowicie dziwnego, zapewniam, że skonfigurowałeś swoją aplikację do budowania jako x86, otwierając właściwości projektu i klikając zakładkę Build. Upewnij się, że "Cel platformy" jest ustawiony jako "x86", a nie dowolny procesor.
Alternatywnie można spróbować znaleźć wersję 64-bitową biblioteki DLL do celów testowych.
Jestem w 100% pewna, że moja aplikacja C# ma 32-bitową. I nawet używany CORFLAGS to sprawdzić: Wersja: v2.0.50727 CLR Header: 2.5 PE: PE32 CorFlags: 3 ILONLY: 1 32BIT: 1 Podpisano: 0 – Coder
@Eric Smith miałam ten sam problem ... to naprawiło to. Dziękuję bardzo! – bsara
+1. Mając ten sam problem i udało się go naprawić. –
OK, wygląda na fałszywy alarm. Nie było to związane z bitness, brakowało tylko innych bibliotek DLL, od których zależy freetype. Jednak komunikaty o błędach mogą być bardziej pomocne.
Połowę rozwiązałem mój problem z BadImageFormatException - zapomniałem skopiować przez zależne biblioteki DLL. Niestety teraz otrzymuję DllNotFoundException na oryginalnej bibliotece DLL ... – jarmond
Proszę oznaczyć to pytanie jako odpowiedź: –
@jarmond upewnij się, że zbudowałeś wersję Release (nie Debugowanie) –
Poza tym, dla potrzeb web-aplikacji rozwiązać uruchomić 32-bitowych aplikacji w IIS 7. Zobacz http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html
miałem ten sam wyjątek w MS Visual C# Express, 2010. Sprawdziłem wszystko budować .dll i .exe z Dependency Walker i MiTeC EXE Explorer, wszystko było zbudowane na 32bit!
W końcu to był następujący wiersz brakuje w moim pliku .csproj:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'MY_CONFIG|x86'">
...
<PlatformTarget>x86</PlatformTarget>
...
</PropertyGroup>
nie wiem dlaczego to brakowało ... Chyba MS Visual C# 2010 ekspresowe nie jest wolną od błędów;)
Przekompiluj bibliotekę dll za pomocą opcji "Any CPU" w Build -> Platform.
To rozwiązało mój problem! Dzięki –
Dowolny procesor nie znajduje się na liście dla mnie. – ShadowMan
Można spróbować sprawdzić opcję "Właściwości" -> "Build" -> "Zezwalaj niebezpieczny kod".
Miałem podobny błąd. Mogłem go rozwiązać, dodając plik ucrtbase.dll lub ucrtbased.dll do debugowania, a także plik vcruntime140.dll lub vcruntime140d.dll w celu przeprowadzenia debugowania w katalogu wykonywalnego. Myślę, że 140 zależy od numeru wersji programu Visual Studio, którego używasz.
ucrtbase.dll zazwyczaj znajduje się w C:\Windows\System32. vcruntime140.dll leży w C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\vcruntime140.dll
można znaleźć więcej informacji tutaj: http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx
dostał ten sam błąd podczas wywoływania 64-bitowej DLL C z C#.Musiałem ręcznie zmienić C# Properties->Build->Platform target z Any Cpu na x64. Podobno Any Cpu to czasami NoCpu.
Gdy tworzysz natywną aplikację/bibliotekę DLL z Visual Studio, zyskuje ona na zależności od pakietu redystrybucyjnego dla tej wersji Visual Studio. To zawiera biblioteki DLL, takie jak msvcr100.dll i msvcp100.dll (dla różnych wartości 100).
W moim przypadku widziałem te pliki DLL w katalogu docelowej maszyny docelowej Windows/system32, więc pomyślałem, że wszystko było dobrze. Okazuje się, że te biblioteki DLL to x64! Nie mam pojęcia, dlaczego katalog o nazwie system32 zawiera 64-bitowe biblioteki DLL. Przeszukałem więc mój katalog Visual Studio 2010 pod nazwą msvc*.dll i znalazłem wersje x86 dla wersji msvcr100.dll i msvcp100.dll. Skopiowałem je na maszynę docelową (w miejscu dostępnym ze ścieżki mojego programu) i wszystko było w porządku.
Mam nadzieję, że pomoże to komuś w konfrontacji z szaleństwem Microsoftu.
Podejrzewam, że wspólna przyczyna tego wyjątku uległ zmianie w ciągu ośmiu lat od pierwszego zadania pytania. Na mojej konfiguracji przy użyciu VS 2017 Okazało się, że odznaczenie "Wolę 32-bit" rozwiązał problem:
Uncheck "Prefer 32-bit" in the Build options
ta sprawiła, że moja 64-bitowej DLL zbudowany z obciążeniem C++ poprawnie. Odwrotnie, zaznaczenie tej opcji powinno spowodować, że 32-bitowe biblioteki DLL zostaną poprawnie załadowane.
Głosowanie na zakończenie jako "nie jest prawdziwe pytanie" - podstawą pytania było nieporozumienie; OP stwierdził, że dana biblioteka DLL ładowała się poprawnie – STW