If you happen to be in the 64-bit world (read running a 64-bit OS on the x64 box, not IA64), there are two options on how your managed code runs.
It can run:
- In a 32-bit process (loads x86 CLR)
- In a 64-bit process (loads x64 CLR)
The high order bit here is the flag under which the image was compiled. Since you cannot compile for 64-bit architecture in .NET Framework 1.0/1.1, and 2.0 is your only choice, let's focus on Visual Studio 2005/.NET Framework 2.0 features.
If you look under the hood on a x64 box, you will find that VS 2005 installer will drop TWO frameworks on your machine.
The 32-bit framework will install in c:\windows\microsoft.net\framework directory, the 64-bit framework will install in c:\windows\microsoft.net\framework64 directory.
If you installed .NET Framework SDK, you will get two SDKs too. One will be in c:\program files\microsoft.net\sdk\v2.0 64bit (64-bit), the other in c:\program files (x86)\microsoft visual studio 8\sdk\v2.0 (32-bit, installed in VS 2005 base directory).
What happens at load time is the CLR runtime host decides on which CLR it needs to load based on the CLR metadata flags. Normally, if you do not change the defaults in VS 2005, your assemblies will be compiled using the 'anycpu' (also known as MSIL flag) which will allow the runtime to host the managed app in a 64-bit process on a x64 box and in a 32-bit process on a x86 box.
You can, however, control and override this default behaviour even after your code has been compiled. There's a handy tool called corflags.exe present in the SDK that allows you to force 'anycpu' compiled code to use 32-bit process in 64-bit world.
More on that in another blog entry.