Assembly.LoadFrom BadImageFormatException - różne zachowanie w .NET 4.0 i 4.5 (ewentualnie nieudokumentowane)

Question

według MSDN documentation,

public static Assembly LoadFrom(string assemblyFile) 

rzuca BadImageFormatException jeśli

assemblyFile is not a valid assembly. 
-or- 
Version 2.0 or later of the common language runtime is currently loaded 
and assemblyFile was compiled with a later version. 

Faktycznie, jest jeden dodatkowy przypadek - Loading zestaw zbudowany dla x86 z zestawu, który działa w trybie x64. Być może jest on zawarty w stwierdzeniu "nie jest ważnym zgromadzeniem", nie wiem. Ale jest to uzasadniona przyczyna wyjątku.

OK, ale w .NET 4.5 to nie działa! Mam aplikację .NET 4.5 WPF, która z jakiegoś powodu ładuje różne aplikacje. Buduje dla każdego procesora i uruchamiam go na Win64 x64. Testowałem go na jednym pliku wykonywalnym, który jest zbudowany dla .NET 4.0 x86 i działał dobrze. Ale kiedy zmieniłem moją aplikację na .NET 4.0, zaczęło się to zawieszać na metodzie Assembly.Load!

Moje pytanie brzmi: czy czegoś brakuje? Jeśli nie, to w jaki sposób to zrobili - ładowanie zestawu x86 z procesu x64 w .NET 4.5? W tej chwili brakuje mi zrozumienia.

Aktualizacja

Dzięki Hans Passant, mam zorientowali się, mój błąd. W rzeczywistości zachowanie Assembly.Load jest nie różni się. Okazało się, że nie zauważyłem opcji Prefer 32-bit w ustawieniach projektu (lub tagu Prefer32Bit w pliku .csproj). Dlatego mój proces w .NET 4.5 ran in a 32-bit mode. To ustawienie było true podczas tworzenia projektu WPF .NET 4.5. Następnie, kiedy został przeniesiony do .NET 4.0, stał się nieaktywny, ponieważ nie było takiej opcji w .NET 4.0. A kiedy przełączyłem się z powrotem na .NET 4.5, stało się fałszywe, co jest tak, jak sądzę, ze względu na kompatybilność.

Answer 1

Szybko usuńmy jedno założenie z tabeli, nie ma możliwości zachowania różnych zachowań na komputerze z zainstalowanym .NET 4.5. Celowanie 4.0 nie robi różnicy w czasie wykonywania. Jedyne, co można zrobić, to wybrać inny zestaw zespołów referencyjnych , uniemożliwiają one przypadkowe użycie klasy dostępnej w .NET 4.5, ale nie na .NET 4.0.

Nie ma możliwości zainstalowania na tym samym komputerze wersji 4.0 i 4.5. .NET 4.5 nie jest równoległą wersją platformy .NET, podobnie jak wersje 3.5 i 4.0 są side-by-side. Instalacja 4.5 zastępuje zainstalowaną wersję 4.0. CLR, jitter, wszystkie zestawy uruchomieniowe oraz kompilator C#.

Najlepiej tutaj skupić się na ustawieniu docelowej platformy w projekcie EXE, to ta, która wybiera stopień zaawansowania procesu. Błędy, jakie można popełnić, to zapominanie, że ustawienie może być inne w przypadku wersji Debug vs Release. I zakładając, że combobox "Aktywnej platformy rozwiązań" w Build + Configuration Manager ma jakikolwiek efekt. Nie ma to znaczenia, ma znaczenie tylko zakładka Project + Properties, karta Build, ustawienie celu platformy. Jest to bardzo niezręczna pułapka, w którą wpada wielu programistów.