Nie można załadować pliku lub zestawu… Podjęto próbę załadowania programu o niepoprawnym formacie (System.BadImageFormatException)

Mam dwa projekty ProjectAi ProjectB. ProjectBto aplikacja konsolowa, która zależy od ProjectA. Wczoraj wszystko działało dobrze, ale nagle dzisiaj, kiedy biegam ProjectB, dostaję to:

Nieobsługiwany wyjątek BadImageFormatException :
Nie można załadować pliku lub zestawu „ProjectA, Version = 1.0.0.0, Culture = neutralny, PublicKeyToken = null” lub jednej z jego zależności. Podjęto próbę załadowania programu o niepoprawnym formacie.

Oba są zwykłymi projektami, bez żadnych zależności od innych projektów nie należących do sieci. Oba są w pełni .Net - nie ma natywnego kodu ani P / Invoke. Mam inne projekty, które zależą ProjectAi nadal działają dobrze.

Rzeczy, których próbowałem:

• Upewnij się, że oba projekty są ustawione na „Dowolny procesor”, a pole wyboru kompilacji jest zaznaczone. Oni są.
• Upewnij się, że oba projekty są dla tej samej struktury docelowej (profil klienta .Net 4.0) .
• W ProjectB -> References -> ProjectA -> Properties, upewnij się, że „Copy Local” jest ustawione na „True” _ (sprawdziłem, że ProjectA.dll jest poprawnie kopiowany)
• Wyczyść / przebuduj rozwiązanie. Próbowałem nawet ręcznie usunąć foldery / bin i / obj w obu projektach.
• Uruchom ponownie Visual Studio. Uruchom ponownie komputer.
• Sprawdź całkowicie nową kopię repozytorium.

Ale nadal pojawia się ten sam błąd. Nie mam pojęcia, co zrobiłem, aby to spowodować, ani jak to naprawić. Jakieś pomysły?

Jestem pewien, że masz konflikt 32-bitowy / 64-bitowy. Wygląda na to, że twój główny projekt może być ustawiony na 32-bit, podczas gdy klasa, do której się odwołuje, jest ustawiona na 64-bit. Spróbuj spojrzeć na to SO pytanie i to też . Między nimi powinieneś być w stanie rozwiązać swój problem.

Być może napotykasz problem ze swoją witryną po wdrożeniu na serwerze.

Następnie musisz dostosować pulę aplikacji, aby włączyć aplikacje 32-bitowe .

Kroki

1. Otwórz Menedżera IIS
2. Kliknij Pule aplikacji
3. Wybierz pulę aplikacji, której używasz

4. W prawym okienku kliknij Ustawienia zaawansowane ...

5. Ustaw opcję Włącz aplikacje 32-bitowe na wartość Prawda

   

Właśnie otrzymałem ten komunikat o błędzie podczas uruchamiania IIS Express w Visual Studio 2015. W moim przypadku musiałem uruchomić 64-bitową wersję IIS Express:

Narzędzia → Opcje → Projekty i rozwiązania → Projekty internetowe
Zaznacz pole „Użyj 64-bitowej wersji IIS Express dla stron internetowych i projektów”.

Zrzut ekranu:

Miałem ten sam problem. Ustawiłem „Platform Target” Projektu A („Project A” (prawy przycisk myszy) -> Properties-> Build -> „Platform Target”) na x86, ale Project B miał „Any CPU”. Naprawiono to, ustawiając Projekt B na „x86”.

Miałem ten problem z uruchomieniem testów jednostkowych (xunit) w Visual Studio 2015 i natrafiłem na następującą poprawkę:

Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64

Może być konieczna zmiana ustawienia puli aplikacji „Włącz aplikacje 32-bitowe” na PRAWDA w IIS7, jeśli masz w projekcie co najmniej 1 32-bitową bibliotekę DLL \ exe.

Przede wszystkim dostałem to w VS2017 ze starym projektem, który musiałem wprowadzić niewielką zmianę i uaktualnić wszystkie projekty do frameworka 4.7.

Kilka innych wspomniało, że wybranie Any CPUmoże rozwiązać ten problem.

Jest kilka miejsc, w których musisz to zrobić, i może to nie być tak proste, jak wybranie z menu rozwijanego. Naprawiłem to dla mnie:

1) Musisz to zrobić tutaj:

2) A także w Configuration Manager(kliknij prawym przyciskiem myszy rozwiązanie)

Ale co jeśli nie ma tam ???

Następnie kliknij Newi wybierz te ustawienia: ( dzięki @RckLN )

Miałem ten sam problem z wieloma projektami w tym samym rozwiązaniu, ostatecznie ustawiłem wszystkie docelowe frameworki na .NET Framework 4 i x86 dla docelowego procesora i ostatecznie udało się to skompilować.

Ten problem może również wystąpić, jeśli próbujesz spakować 64-bitowy projekt za pomocą instalatora MSI w VS. („Powodem jest to, że natywny shim zapakowany z plikiem .msi jest 32-bitowym plikiem wykonywalnym.”)

Zobacz tutaj po więcej szczegółów: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx

Żadne z tych rozwiązań nie działało dla mnie - ale po usunięciu zawartości folderów bin i obj wszystko znów było fajne.

Mam to podczas budowania projektu za pomocą kompilacji Visual Studio Online (VSTS) za pomocą Visual Studio BuildSteps.

Rozwiązaniem było:

• Usuń istniejący folder źródłowy
• Jawnie ustaw „Dowolny procesor” na platformie dla wszystkich kompilacji Visual Studio, w tym zależności (patrz zrzut ekranu poniżej).
• Uruchom ponownie kompilację

Poniższy problem rozwiązał dla mnie, odznacz „Preferuj 32-bit”:

Napotkałem ten sam problem. Wyskoczył z nieba i to wydało mi się dziwne.

W migawce wyjątku dla FusionLog widziałem w jej komunikacie:

... C: \ Windows \ Microsoft.NET \ Framework64 ...

Więcej informacji na temat dziennika syntezy: http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx

Wszystkie projekty miały docelowy procesor AnyCPU. Zmieniłem projekt aplikacji (projekt, który odwołuje się do wszystkich innych projektów) na docelowy procesor x86. Teraz działa.

Nie jestem pewien, jak doszło do pomieszania docelowego procesora bez wyraźnego powodu, ale tak się stało.

Mam również ten problem w projekcie, po kilku minutach znalazłem rozwiązanie, ten problem jest spowodowany konfiguracją procesora. Jeśli używasz Visual Studio 2010 lub VS 2013 , po prostu weź właściwości projektu, a następnie wybierz Kompiluj z paska bocznego i będzie 5 rozwijanych, 5 rozwijanych będzie docelowy procesor: powinieneś ustawić go na x86 lub x64 zgodnie z własnymi wymaganiami zamiast dowolnego procesora.

Mój problem został rozwiązany po zmianie na x86.

Może się to również zdarzyć po prostu przez zdefiniowanie wielu obsługiwanych frameworków w pliku app.config i zmuszenie aplikacji do działania w innym frameworku .NET innym niż ten wymieniony jako pierwszy w pliku app.config .

Uruchamia się również, gdy masz oba wymienione frameworki dostępne w systemie.

Aby obejść ten problem, przywołaj strukturę docelową, której zamierzasz użyć do debugowania w pliku app.config

np: jeśli próbujesz uruchomić w .NET 4, plik konfiguracyjny powinien mieć coś podobnego do tego,

<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>

W moim projekcie dla C #, właściwość projektu -> [Kompilacja] -> Cel platformy: Dowolny procesor i odznacz 32-bitowy Prefer, aby umożliwić kompilatorowi wybór automatycznie.

Zespół Chilkat .NET 4.5 wymaga zainstalowania środowiska wykonawczego VC ++ 2012 lub 2013 na dowolnym komputerze, na którym działa aplikacja. Większość komputerów już go zainstalowała. Twój komputer programistyczny będzie go miał, ponieważ program Visual Studio został zainstalowany. Jednak w przypadku wdrażania na komputerze, na którym wymagany środowisko wykonawcze VC ++ nie jest dostępne, wystąpi powyższy błąd:

Zainstaluj wszystkie poniższe pakiety

Pakiety redystrybucyjne Visual C ++ dla Visual Studio 2013 - vcredist_x64

Pakiety redystrybucyjne Visual C ++ dla Visual Studio 2013 - vcredist_x86

Pakiety redystrybucyjne Visual C ++ dla Visual Studio 2012 - vcredist_x64

Pakiety redystrybucyjne Visual C ++ dla Visual Studio 2012 - vcredist_x86

Jeśli używasz LibreOffice ze swojego programu poprzez integrację z cli .net, tak jak ja, mam ten sam błąd. Używam starszej wersji LibreOffice w środowisku produkcyjnym na komputerze. Zainstalowałem nowszą wersję, która była w konflikcie. Po prostu odinstaluj LibreOffice. Znalazłem rozwiązanie tutaj .NET CLI: Nie można załadować pliku lub zestawu „cli_cppuhelper”

Może to być trochę zabawne, ale miałem ten sam problem z normalnym działającym kodem. Dodałem StreamWriter i StreamReader i dało to błąd. Rozwiązaniem było wzięcie tego kodu do nawiasów komentarzy, a następnie debugowanie i zaczęło działać ponownie

Miałem również ten problem z uruchomieniem testów jednostkowych przy użyciu ReSharpera w Visual Studio 2017 i naprawiłem go za pomocą następującej konfiguracji:

Możesz także zmienić ustawienie testu uruchamiania ReSharpera: https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64-configuracja

W moim przypadku brakowało zależności w bibliotece dll, która zgłosiła ten wyjątek. Sprawdziłem za pomocą Dependency Walker, dodałem brakującą bibliotekę DLL i problem został rozwiązany.

Mówiąc dokładniej, jakoś zepsułem mój plik opencv_core340.dll przez przypadkowe dodanie do niego słów kluczowych SVN, a zatem moja biblioteka dll nie mogła go już używać. Jednak nie wierzę, że rozwiązanie tego problemu zależy od tego, czy dll jest uszkodzony, czy go brakuje. Dodam to tylko w celu podania pełnych informacji.

Strzelać! Wiedziałem o tym problemie. Myślałem, że robię wszystko dobrze, dopóki przypadkowo nie zobaczyłem „x86” w oknie wyjściowym VS i wtedy zrozumiałem przyczynę. Zmarnowałem dziś kilka minut.

Konfiguracja w oknie „Publikuj” została ustawiona na „x86”; podczas gdy wszędzie indziej było to „x64”.

Upewnij się, że jest zsynchronizowany w menedżerze konfiguracji, ustawieniach publikowania, konfiguracjach rozwiązań i ustawieniach IIS (jeśli to twój serwer WWW).

Pamiętaj też, że VS to aplikacja 32-bitowa, a IIS to wersja 64-bitowa. Aplikacje 32-bitowe są domyślnie wyłączone w IIS.

Wykryłem coś innego niż inne odpowiedzi. Osiągnięcie tego wyjątku w moim projekcie było wynikiem uszkodzonej kompilacji. Naprawiono bez wprowadzania jakichkolwiek zmian, tylko zmuszając do przebudowy .

Miałem ten sam problem. Projekt B w moim przypadku to biblioteka .Net Core Class Library z zainstalowanym programem Nuget „Microsoft.Management.Infrastructure”. Błąd polegał na tym, że nazwałem mój projekt B „MI”. Zmieniłem nazwę projektu na coś innego i nagle wszystko znów działało.

Moja maszyna pokazała mi aktualizację systemu BIOS i zastanawiałem się, czy to ma coś wspólnego z nagłym pojawieniem się tego błędu. Po tym, jak zrobiłem aktualizację, błąd został rozwiązany, a rozwiązanie zbudowało się dobrze.

Czy próbujesz uruchomić plik .exe z cmd? To był mój błąd. Wystarczy uruchomić plik .exe, klikając go dwukrotnie. Jeśli jest to .NET Core SCD dla Windows 8.1 / Windows Server 2012 R2 x64.