Why am I Able to load x64 assembly into AnyCPU Prefer 32 bit executable?

Question

I am working on a tool that loads different assemblies using System.Reflection 's method Assembly.Load Here is what i get On a 64bit OS, if application configured with:

• x64 loads x64 & AnyCPU Assembly
• x86 loads x86 & AnyCPU Assembly
• AnyCPU loads x64 & AnyCPU Assembly

Now when it's configured with AnyCPU Prefer 32 bit on 64 bit OS,it will be running on 32bit process as it said here

In .NET 4.5 and Visual Studio 11 the cheese has been moved. The default for most .NET projects is again AnyCPU, but there is more than one meaning to AnyCPU now. There is an additional sub-type of AnyCPU, “Any CPU 32-bit preferred”, which is the new default (overall, there are now five options for the /platform C# compiler switch: x86, Itanium, x64, anycpu, and anycpu32bitpreferred). When using the "Prefer 32-Bit" flavor of AnyCPU, the semantics are as follows:

• If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
• If the process runs on a 64-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
• If the process runs on an ARM Windows system, it runs as a 32-bit process. IL is compiled to ARM machine code.

The difference, then, between “Any CPU 32-bit preferred” and “x86” is only this: a .NET application compiled to x86 will fail to run on an ARM Windows system, but an “Any CPU 32-bit preferred” application will run successfully.

My Question is: Why it loads x64 assembly without any problem? isn't that a strange behaviour?

I have seen this question ODP.NET x64 ANYCPU and Prefer 32-bit setting that support this proposition

Answer 1

.NET assemblies (exe and dll) don't contain x86/x64 assembly. They contain IL (intermediate language), which is architecture-independent. At runtime, the JIT turns the IL into x86/x64 machine code, as appropriate.

The "Any CPU" and "Prefer 32-bit" settings, etc, only change some bits in the header of the assembly, which tells the JIT what to emit at runtime. Only the bits in the header of the.exe matter: the exe dictates what the JIT will emit, and the if the JIT is emitting eg x86 for the exe, it will do the same for all other assemblies which are loaded into that process.

Now, it might be a bad idea to load a dll which has the "x86" flag set into a process which the JIT is emitting x64 for: presumably that dll has a reason for specifying x86, and that's probably because it's invoking some native code which is compiled for x86. If you force it to run inside an x64 process, then it won't be able to invoke that x86 native code any more.

(Note that the landscape has moved since that quote you found: .NET Core now ignores "Prefer 32-bit", and AnyCPU defaults to x64).

Answer 2

The AnyCPU option allows the .NET virtual IL code in the executable binary file to be run on 32-bit as well as 64-bit computers.

AnyCPU prefers 32-bit indicates to run the process in 32-bit compatibility mode on x64 machines, unless of course some cause prevents that.

It is a parameter at runtime, not at compilation, as explained @canton7 .

What is the purpose of the "Prefer 32-bit" setting in Visual Studio and how does it actually work?

If the application loads 64-bit DLLs, it means the code is executed ( translated ) in 64-bits native machine code , otherwise we would get a system error box.

Having a virtual assembly for a virtual OOP (single inheritance yet) computer is the purpose of DotNet.

If we look using any Task Manager we will see that the process is indeed x64 and not x32.

What is said in the following links about x32-x64 is valid for x64-x32:

Is it possible to load a 64-bit dll into a 32-bit process?

Calling 32bit Code from 64bit Process

Load 32bit DLL library in 64bit application

Process Interoperability

To be able to load a DLL of a different architecture than the highest one, we need certain things like creating a sandbox. For example, Renoise can run 32-bit VST while the DAW is 64-bit.