What technologies can be used to call from a native process to a C# process?

Question

I have a native (C++) process and a managed (C#) process on the same system. I want to enable communications between the two, similar to how one could use RPC between two native processes. I know I could use WCF using Microsoft's WWSAPI in the native process., but I was wondering what other options do I have? Or is WCF the best/only solution?

Answer 1

Just to name a few . file based, TCP/IP, pipes, named pipes, Mailslosts, MQ,windows messages,

Answer 2

If you want to communicate between two processes, you have a wide range of options, as rerun said in his answer. To his list you can add shared memory (memory mapped files) and named synchronization objects like semaphores and events. I'm sure there are others.

If you want the C++ application to call functions in the C# application, your options are more limited. WCF is not the only solution, and maybe not even the preferred solution. You can expose the C# as a COM interface. Here's one way to do it. http://support.microsoft.com/kb/828736

Answer 3

Take a look at Apache Thrift:

Thrift is a software framework for scalable cross-language services development. It combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml.

Originally developed at Facebook, Thrift was open sourced in April 2007 and entered the Apache Incubator in May, 2008.

Answer 4

If the C++ program is "in charge" then COM Interop as mentioned by @Jim is probably your only choice. If it's more of a two way thing you can also do "reverse PInvoke" (not an official name) where the C# code turns a delegate into a function pointer, and PInvokes a (flat C-style) function in the C++ code, passing in the function pointer, and then later the C++ code uses the function pointer to run whatever C# method is sitting at the end of the delegate. While this takes a little more plumbing it spares you the perf hit of COM Interop. Or if you're feeling really brave, you can write a managed C++/CLI class that calls your C# code in the usual way, and with the help of the gcroot<> template, call it from your native C++ code.

http://www.gregcons.com/KateBlog/CallingManagedCodeFromNativeCode.aspx has a link to a blog entry for that third way. http://www.gregcons.com/KateBlog/IntroToCOMInterop.aspx, which is almost 4 years old, has a link to an MSDN article that expands on the first two options a little.

PS: Web services as a way to communicate between two programs on the same machine written by the same developer is almost never the right answer. Not that it wouldn't work, but there are faster and easier ways if you control both ends.