How to make a C# console utility attach to a C++ exe?

Question

I've got a Win32 C++ game side project and I'd like to create a C# process that can be dynamically attached. The C++ process could then send debug data to the C# process and the C# console could send debug commands to the C++ process. I know this can be done, but I'm not sure how to do it. Anyone know?

Answer 1

There are plenty of ways to communicate cross-process. For your purposes, I would recommend you use Sockets to communicate between the two, as this will also allow you to communicate between machines if you like; and the semantics of using Sockets are similar in both languages.

On the C# Side, you can get started with Sockets by using the Socket or TcpClient class in System.Net.Sockets. Also, you'll probably find it a little bit easier to implement the server / listening side in the C# process.

TcpClient Class @ MSDN
Socket Class @ MSDN
System.Net.Sockets Namespace @ MSDN

On the C++ Side, you have two means of utilizing sockets, either via WinSock functions or Unix/POSIX style functions.

Getting Started with Winsock @ MSDN

Winsock Functions @ MSDN

Note that the WSA**** functions are the formal WinSock functions, and select / listen / bind / ... are the traditional Unix/POSIX style ones. You can use one set or the other.

TCP Sockets are probably your best bet; but you may find that UDP allows you to get started quicker. Also, you could potentially do interesting things with UDP multicast. Don't forget to check your firewall settings if you use sockets.

Other possible means of communicating between the two involve varying amounts of work and domain knowledge that you may need to learn. Here's a brief outline with Pros and Cons.

Named Pipes

Pros: Excellent performance on the same machine, easy to control in C++.
Cons: Difficult to use across machine boundaries.

COM Application Server

Pros: Easy to consume on the C# side. Once created, easy to extend on the C++ side.
Cons: Can be difficult to debug, and it is tricky to add support to an existing project. Also prone to COM registration and debugging headaches. Difficult to learn to use across machine and user-session boundaries.

Shared Memory

Pros: Superb performance, easy to control in C++, moderately easy to control in C#.
Cons: Cannot be used across machines. Has quirks in sharing buffers across processes, though you can always create a buffer for each side, and make communication one-way for the buffers. This is tricky to use if you have more than 1:1 communication between your apps.

Answer 2

We are doing something very similar using named pipes in one of the projects that I am working on. Although I didn't work on the implementation it seems to be doing the job very well. The following link gives a good overview.

http://msdn.microsoft.com/en-us/library/aa365590(v=vs.85).aspx