Home/ Questions/Q 9019307
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T04:44:44+00:00

According to MSDN documentation , public static Assembly LoadFrom(string assemblyFile) throws BadImageFormatException if assemblyFile

  • 0

According to MSDN documentation, 

public static Assembly LoadFrom(string assemblyFile)

throws BadImageFormatException if

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.

Actually, there is one extra case – loading assembly that is built for x86 from assembly that runs in x64 mode. Maybe it is included in “not a valid assembly” statement, I don’t know. But this is reasonable cause of exception.

Ok, but in .NET 4.5 it doesn’t! I have a .NET 4.5 WPF app, that loads different appliations for some reason. It is building for Any CPU and I’m starting it on x64 Win 7. I’ve been testing it on one executable, that is built for .NET 4.0 x86, and it worked fine. But when I switched my app to .NET 4.0 it began to crash on Assembly.Load method!

So, my question is, am I missing something? If not, then how did they do that – loading x86 assembly from x64 process in .NET 4.5? I’m lacking some understanding at this point.

Update

Thanks to Hans Passant, I’ve figured out my mistake. Actually the behavior of Assembly.Load is no different. It turned out, I didn’t notice Prefer 32-bit option in project settings (or Prefer32Bit tag in .csproj file). That’s why my process in .NET 4.5 ran in a 32-bit mode. This setting was true when I created WPF .NET 4.5 project. Then, when I swithced to .NET 4.0 it became inactive because there was no such an option in .NET 4.0. And when I switched back to .NET 4.5 it became false, which is so, I guess, for compatibility purpose.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Let’s clear one assumption off the table quickly, there is no possible way to have different behavior on a machine that has .NET 4.5 installed. Targeting 4.0 makes no difference at runtime. The only thing that does is select a different set of reference assemblies, they prevent you from accidentally using a class that’s available on .NET 4.5 but not on .NET 4.0.

    There is no way to have both 4.0 and 4.5 installed on the same machine. .NET 4.5 is not a side-by-side version of the .NET framework, like 3.5 and 4.0 are side-by-side. Installing 4.5 replaces an installed 4.0 version. The CLR, the jitter, all the runtime assemblies plus the C# compiler.

    It is best here to focus on the Platform target setting of your EXE project, that’s the one that selects the bitness of the process. The kind of mistakes you can make is forgetting that the setting can be different for the Debug vs the Release build. And assuming that the “Active solution platform” combobox in Build + Configuration Manager has any effect. It doesn’t, only the Project + Properties, Build tab, Platform target setting matters. This is a very awkward trap that many programmers have fallen into.

    • 0