The .Net framework gives developers the powerful option of compiling assemblies targeted for the now-standard x64 platforms or legacy x32 platforms. This is not an issue for most modern software since the typical machine is based on 64-bit architecture and most assemblies are compatible with 64-bit systems.
However, the challenge arises when compiling 64-bit assemblies using 32-bit COM libraries, which are abstracted by 32-bit interoperability wrapper DLLs that “convert” the binary COM structure to the standard .Net MIDL model. In this case, although the assembly will compile successful without errors, the runtime will fail with an entry point or “file not found” exception.
32-bit assemblies and executables will operate properly on a 64-bit system, but x64-based solutions will not operate on 32-bit systems. Normally, none of these issues are a true concern when developing applications and solutions since most developers will leave the default configuration build options at Any CPU. There may be times when you need to develop a solution that integrates into an external app (like Dynamics GP) that is, at its core, still 32-bit. In that case, it is perfectly reasonable to set the compilation mode to x32. This will work as expected on an x32 system. It will even work on an x64 system if the assembly does not include any COM interops. Nonetheless, it will generate runtime errors if executed on an x64 system with x32-based COM references. If you try to correct that by switching the compilation to x64, it will now fail on 32-bit systems and will likely still generate runtime errors on 64-bit platforms using the 32-bit COM engine.
Thus, to truly develop assemblies that are platform independent in terms of 32-bit or 64-bit processing, use Any CPU when compiling solutions that depend on 32-bit COM interop DLL wrappers.
