Ensure a .NET App Works in Both 32 bit and 64 bit Environments

With 64 bit versions of Windows fast becoming the standard it is imperative that an app work in both 32 bit and 64 bit environments. This done using a basic configuration setting, with a few caveats of course. In Visual Studio in the project’s build options you can select the app’s Platform target, which can be x86, x64, Itanium, or Any CPU (the listing you see may vary, depending on what you have installed with Visual Studio).

Unless there is a good reason not to, you should always select Any CPU see below:

Since .NET assemblies consist of byte code that is  JIT (just-in-time) compiled to the current platform at runtime, an app’s assemblies will function on any architecture without needing to rebuild from the source code.

However, the choice is not always that simple. If your .NET assembly references or interops with another managed assembly or an unmanaged DLL which was compiled for a certain architecture, then your app’s .NET assembly will need to match the assembly or dll’s.

Take for example a scenario where you  have the following:

• .NET assembly: Any CPU
• 32-bit COM component

On a 32-bit OS this scenario will work fine since the .NET assembly will be JIT  compiled as 32 bits. However, this will fail on a 64-bit OS since the .NET assembly will be 64 bits and when it attempts to call into the COM component the app will break. In such a scenario, it best to specify that the assembly should always be 32 bit.

Note that x64 OSs  run 32-bit processes just fine. Also bear in  mind  that while .NET itself mostly insulates you from platform architecture considerations, when you using unsafe code, pointers, or relying on the size of IntPtr, you will likely encounter issues when running on multiple architectures.