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?
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.
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
Related
I would like to build a communication protocol between COBOL and C# applications. I didn't find the right way to connect these two applications. The only possible way is to write data by COBOL to a file and read it by C# application and vice versa.
Can I use socket techniques to create such communication, because the file method has bad performance? Or are there any other methods of communicating data between these two languages?
Can I use socket techniques to create such communication [...]?
Of course! You just need to make one a socket server and the other the client + creating + implementing a protocol (if it is just one client + server and you don't need secure communication this is quite easy). You may already have a socket option in your COBOL environment or use external libraries like the free CBL_GC_SOCKET (works for many COBOL implementations, as long as they can call C/C++ binaries).
Or are there any other methods of communicating data between these two
languages?
A multitude (especially if they run on the same machine).
Depending on the COBOL environment used you may have a direct .NET-assembly option and CALL/invoke, or can write a layer to do so with running COBOL code translated to native code within C#.
Direct input/output is often a solution (depends on the needs and the environments, not all have a bi-directional pipe option).
talk to a message queue server (likely not superior in performance)
if the COBOL environment supports it: create a REST endpoint and use this for communication; or do it the other way around talking from COBOL to a REST service implemented in C# (REST from COBOL is likely the "most portable" way of those mentioned, but also the one with the worst performance)
...
Conclusion: there is nothing that hinders COBOL to "communicate" with any reasonable "other programming language", you mainly have to see what you're COBOL and "other programming language" provides and what your goals are.
I've recently taken some classes in networking (CCNA 1 through 4), so I understand most of the theory behind it all. What I'd like to do now is take that knowledge I have and put it into practice in the form of some small applications.
I've been reading through some articles on MSDN on how to do this, but they seem to only cover network programming at layer 3 or 4 and upwards, IIRC. What I'm looking for is some simple examples of how to deal with layer two connectivity (ie. framing) between hosts, or even just something simple like how to perform an Ethernet broadcast.
I have a little experience with C# and C++, so examples which use either of those languages would be great.
Thanks.
For Windows, have a look at WinPcap which provides low-level network access. The developer pack already contains some simple examples to get you started.
BTW, on Linux there are packet sockets.
You could use the eEx Network Library to write small apps (I have done the same thing during my CCNA).
It is an easy-to-use and object-oriented .Net programming library, which lets you go down to layer 2 and send out custom frames via WinPcap.
Frame types like Ethernet, ARP, IP, UDP, TCP and RIP are implemented, and as far as I know, these are protocols which occur during CCNA.
Tutorials in C# are available here, and if you want look at something in depth, like address resolution, you can always have a look at the source code, since the library is open source.
Very probably, you could study low-level network utilities on GNU/Linux systems, or also look into the kernel TCP or UDP or IP layers. But for instance, doing an Ethernet broadcast is something very low level, and not very useful. And real examples (usually coded in C, not C++) probably can't be simple because they have to deal with error handling.
I have a C# server application and it needs to talk to and control another 3 client applications: one in C#, one in C++ and one in VB.Net. All of them are Windows Form applications. They basically need to exchange some strings and numbers, not heavily loaded. What is the best way to do IPC between C# and those different languages? Note that clients don't talk to each other, they only talk to the server.
C# needs to talk to C++ so I guess WCF isn't good, as WCF only works between two .Net applications?
Can I use named pipes conveniently in all these languages: C#, C++ and VB.Net?
I also want to know if in the future I have to add VB6, VBScript and PowerShell scripts as clients, what would be the best IPC option that works for all these 6 languages? Will I still be able to use named pipes?
Actually WCF configured to expose services via HTTP might be the best option for the list of languages you want to support.
If you don't like WCF consider exposing HTTP REST interfaces i.e. by writing server in ASP.Net MVC.
Named pipes support - C#/VB.Net, C++ - good, VB6 - I don't know, VBScript - definitely not out of the box, PowerShell - yes as it can use .Net libraries.
The fastest solutions for the languages you listed are named pipes and, better still, memory mapped files. Both have implementations in .NET 4.0 and unmanaged C++.
I would recommend looking into memory mapped files. It's relatively straighforward to create a file and an associated view that serve as single-producer, multiple-consumer, unidirectional channel. You can use, say, the first 4 bytes of the area to store the updated value of the last byte written (modulo the view size - 4 bytes) and an EventWaitHandle to synchronise producer/consumer access. Two channels accessing separate memory mapped files will give you a duplex channel.
Links for .NET (C# and VB.NET) and
unmanaged C++.
You may then want to look into Protocol Buffers as a very efficient way to serialise your binary data.
0MQ is an excellent product in the Linux space but the Windows version is somewhat stripped-down, and among other things doesn't support IPC.
There are different libraries you can try such as OpenDDS, ZeroMQ and others. Though ZeroMQ on Windows does not support IPC yet (but supports TCP).
I'm starting to write a program which communicates with serial/parallel ports. I'm not sure whether I should write it with C# or C++.
I prefer C# because it's my preferred language and I have written applications (high level) with it. But I'm not sure if it can handle port communication in all circumstances. (For example once I wanted to develop a filter driver and found out it couldn't be done at all using C#. So I'm in doubt about port programming limitations as well.) Usually people go with C++ in these situations. (why?) Is there any limitations in C# I should be aware of regarding this matter?
Since you need fine control over the port (ie, the ability to bit-bang and send raw data), then you need an extra component to do this in .NET. See http://www.lvr.com/parport.htm for an example.
There is no managed way to do this, but by using external components, you can develop in your familiar environment. This is probably the way to go, since dealing directly with ports is a life-consuming process.
I have a C++ application with data that needs to be shared with a C# application.
I'm currently transferring the data via files, but with speed and quantity of the data becoming an issue I would like to find a way to share the data through memory.
I'm a beginner to intermediate programmer at best, and so far I have heard of two methods that may be able to help me do this: Socket Programming & Memory Mapped Files
So my questions is, which is the best way to do this? (yes, speed is a factor)
and any info or links to info that could help me in my research and comprehension of the method you suggest would be very much appreciated.
Thank you,
You could use named pipes for interprocess communication. I haven't used it from c++ land yet though..
Sockets, IMO. It is standard, fast (even more so if you are running in the same machine) and very flexible. Memory mapped files I'm not sure if it is supported by C# but I could be wrong.
This is a fairly difficult question, mostly because there is no right answer. You definitely could use sockets or memory mapped files to communicate between two processes. Other alternatives are COM or simply posting a windows message from one process to another.
.NET - COM interoperability
Erm. I would suggest a different approach. I believe you would find it much easier to make an object (or objects) in managed C++. You can keep everything in your project native C++, except this file/class, which you would compile with /clr.
The /clr class will be able to interop trivially with .net, since it is .net. Then you can add regular C++ methods to the object to get data in and out as you see fit. Typically I would suggest copying data across the boundary so you don't need to screw around with pinning or anything.
It takes a little getting used to, but this approach is very flexible.
Here's a little something that talks about it better than I can: http://blogs.microsoft.co.il/blogs/sasha/archive/2008/02/16/net-to-c-bridge.aspx
I'd probably suggest googling interprocess communication to do this. Each OS has a different method, but you basically need to signal one application from the other (with the signal encoding the data and datatypes).
Using sockets is a good method, but has the problem that if the loopback address of the machine is kaput (which can easily be done through mis-configuration while playing around with ip stuff) then your app won't be able to communicate. On a more serious note, if the loopback address is compromised and made to point at an attackers machine then your application is suddenly sending data to a malicious source, although this may or may not be a problem for you.
Memory mapped files aren't natively available in C#, but you could probably do something using P/Invoke.