components can be used in an application with different target instruction-set
architecture, including ActiveX controls.
Please see: http://en.wikipedia.org/wiki/Instruction_set
This is because every process can only work with executable modules of the same target architecture. If you try to dynamically link or load a module of different architecture (even supported by the present instance of OS), it may "work" but crash during run-time.
Of course, COM provides a way to work across this boundary, but only those working as separate processes, such as COM servers. They work with applications through IPC, which of course resolves the problem.
Some background: on a 64-OS, two target instruction-set architectures are supported: one of the "native" 64-bit architectures plus x86, which is available, because 64-bit CPUs support compatible 32-bit segments and x86 instruction set. On Windows, this is done via WoW64:
In this case, every process is started either under WoW64 or as a native 64-bit process (x86-64, Itanium) supported by CPU and the version of Windows. All other executable modules loaded in the process should be compiled for matching target architecture.
Compile your entry assembly of your solution with the target architecture "x86". All other assemblies used in your application can better be compiled with "Any CPU". When your entry assembly is loaded with all other assemblies, the resulting instruction set of the process (used by JIT) will be set to "x86", because it is defined by the combination of entry assembly setting and architectures actually supported by the OS. In this case, your process will be able to use x86 ActiveX control.
Just in case, if this is not obvious at the moment:
You can have the case of using some assembly which uses 32-bit ActiveX control but that assembly is not uses as an entry assembly. I would advise to compile it to the target "x86" as well, because, if it always uses 32-bit control, there are no cases when it can use different target instruction-set architecture.