All 64-bit platforms (there are two Intel instruction-set architectures, IA-64 (Itanium) and x86-64, see
http://en.wikipedia.org/wiki/Itanium[
^],
http://en.wikipedia.org/wiki/X86-64[
^]) work on the platform of WoW64, see
http://en.wikipedia.org/wiki/WoW64[
^].
All three instruction-set Intel architectures are incompatible, but a 32-application is compatible with both 64-bit instruction-set Intel architectures. The problem is: executable modules with different target architectures cannot be used in the same process. The solution with such projects using each other will build into assemblies, but they will crash during run-time.
Now, the delicate aspect is the target platform "Any CPU". As .NET code is JIT-compiled, such executable modules will be JIT-compiled during run-time due to the physical architecture they are loaded on. This is if all the projects were compiled "Any CPU". If not, the actual run-time will be defined by the entry assembly of the application. In case of conflict — see above.
Another problem is P/Invoke which can tie .NET assembly to a certain instruction-set architecture or, just the opposite, link it to a different architecture after moving to 64-bit platform while you require 32-bit version, simply because the DLL under the same names comes in 64-bits. Such problems are more difficult to detect. One good tool to help is Microsoft Dependency Walker, see
http://en.wikipedia.org/wiki/Dependency_Walker[
^],
http://www.dependencywalker.com/[
^]. You really need to know all your dependencies in unmanaged codes.
—SA