Loading COM in a process which is compiled using different visual studio compiler version

Question

We have a executable compiled using Visual Studio 2008 version. Due to the 3rd party dependency we must compile this executable in visual studio 2008.

We also have another component which gets compiled in visual studio 2010. Now we need to get one COM component dll from this component (which is compiled in 2010 compiler version) accessed by the executable which is compiled using 2008 compiler version.

My question here is, would it work fine. Would there be conflicts in the runtime used by the executable (which is 2008 runtime lib) and runtime used by the COM component (which is using 2010 runtime).

We actually tried to load this COM dll in executable which actually worked fine. But I have concern that in later time due to multiple runtimes it may crash/fail.

Please let me know how the multiple runtimes would get handled here. Is it safe to load the different runtime in single executable. Would there be any conflicts in later part of execution due to different runtime available?

Anyway a solution we are looking to solve this problem to make the COM component as a OUT proc Server, which anyway will work. But that will involve a lot of work to do.

Please let me know.

Many Thanks

Answer 1

You should have no problem mixing COM objects that are linked with different runtime libraries, since the memory allocation and deallocation of each object will be done behind the DLL boundary.

You need to be careful that all your methods have proper COM signatures, i.e. all pointers should be COM pointers.

Answer 2

COM is designed for binary interop. By design the framework is implementation agnostic. The intent is that COM servers can be implemented in one language/runtime, and consumed by a COM client implemented with a different language/runtime.

There are absolutely no constraints over the languages and runtimes that are used by different parties.

Answer 3

This has been answered a few times in several contexts.

As long as you don't handle and/or pass around C runtime (CRT) data structures between modules, you're fine. If you do any of the following between modules that depend on different CRTs, you'll have trouble, and in this specific case, you're not implementing COM objects properly:

• malloc memory in one module and realloc or free in another
• fopen a FILE* in one module and fread, fwrite, fclose, etc. in another
• setjmp in one module and longjmp in another

Note that there are things you can do:

• Use memory malloced by another module, keeping the responsibility of reallocating and freeing on the originating module
• Use some interface that interacts with files fopened by another module, keeping the responsibility of its use on the originating module
• Don't use setjmp/longjmp across unrelated or losely coupled modules, define callbacks, aborting error codes, whatever, but don't rely on unwinding techniques, even if provided by the OS

You can see a pattern here. You can use resources from another module for as long as you delegate managing those resources to that module.

With COM, you shouldn't ever have this kind of trouble, everything should be encapsulated in objects through their implemented interfaces. Although you can pass malloced memory as top-level pointer arguments, you're only supposed to access that memory in the callee, never reallocate or free it. For inner pointers, you must use CoTaskMemAlloc and its cousins, as this is the common memory manager in COM. This applies to handling files (e.g. encapsulate them in IStream, IPipeByte, a IEnumByte or something similar), and don't unwind across COM calls.