Since some necessary underlying sub-modules are not available in a 64bit version, this problem must be addressed differently than by a 64bit compilation. As Microsoft suggests Sumex1 uses the out-of-process proxy approach where a 32bit COM server loads the 32bit COM dll into its process space and delegates each method call to the dll. Since a 32bit COM server exists in its own process space, the main 64bit process can handle the 64/32bit boundary without problems.

As a result, each 32bit Sumex1 COM dll has a 32bit COM server counterpart with the same name and an oopProxy prefix, e.g. oopProxyMigelValidator100.exe, where the prefix signifies the out-of-process proxy nature of the executable.

Any 64bit software now creates an instance of the 32bit oopProxy server and then calls the same methods and properties as with the 32bit COM dll. However, there is one crucial difference when using the oopProxy mechanism, namely the necessity to forcefully unload to the COM server at the end e.g. by using Marshal.ReleaseComObject() since the automatic garbage collection approach is too error prone.