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.
Related
I'm working on a project that uses an RFID reader, which only works with a library in C#. The thing is I'd really like to work with Java (develop the rest of the program, GUI, etc), and use the C# program just to ask the reader to read the information and return a string to the Java program.
So, is there a way I could do this?
Thanks in advance.
One way to approach this is to look at it as a problem of interprocess communication. There are a bunch of options (assuming Java has access to the necessary Windows API's which I'm assuming it does, but I'm not really a Java dev).
Named Pipes, TCP/IP, Filesystem, Mailslots, etc.
Here's a good article on some options: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365574(v=vs.85).aspx
Another option, which I don't know enough to speak about, is trying to load a .Net library into your java process.
Couldn't you use sockets?
They both do support it, but I never tried to do it between different languages.
Good luck.
If you don't mind delving too deep you could use the Java Native Interface to generate code to marshall calls from Java to C# and back again. You'd need to build a "bridge" in c/c++ (c++ is generally slightly easier).
This way you get in-process communication, which is the fastest way to work :-)
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
I have a very simple problem. I have an application which is written in Delphi 2007 for WIN32. It uses a C# DLL which is imported into the project through it's COM interface and a simple trick to avoid registering the COM object. But now I have a Java-generated .JAR file that I want to call from my application. And while I have access to the Delphi and the C# code, I just don't have access to the Java code.
I can do two things. Either I call the Java class from the Delphi code, which would then be called from the C# code which is called again from the Delphi code. Or I just call the Java code directly from C#. (Which is called from Delphi again.)
I know this is a complex setup. The Delphi application contains a GUI and some communication modules for some special hardware. There are no .NET drivers for these. The C# code is there to maintain database communication and includes some logic related to CardSpace and other security options. The Java class is a third-party encoding module which is created by an outside party which calculates a special hash code over data in the database and does some additional processing and which controls yet another piece of hardware.
Biggest problem: no network communications! It will run on a special computer which has no network hardware installed. It's a stand-alone Windows XP system. While COM, Java and .NET are okay, I cannot use any TCP/IP communications on this system.
This would be my next project if I accept it. Already, it's giving me a headache so I think I'll skip this chance, although it does have an interesting mixture of several different languages. I think I'll just tell them to invest a number of 6 digits to buy new hardware instead of spending an amount of nearly 5 digits for 28 days of my work...
A few details about the project that I can share:
The Delphi code is able to connect to a PBX system through a COM port which it uses to send faxes, send and receive SMS messages and to receive simple commands by just entering digits with a phone after calling in. A whole system has been written for this, all based on WIN32 code.
The Java code is a client-side module to communicate with a robotics system that monitors the environment, handles a few delicate objects and does constant measurements of those objects. It's in Java so it's platform-independent. The communication between the Java client and the robotic hardware is done through the network and the network hardware/drivers don't like additional chatter over this network. (Which is why it's disabled as much as possible. Not even Windows will get updates.)
The C# code is to collect the data from the Java module and to actually store this in-memory writing regular backups in XML, just in case something happens. It's to communicate with the Java module and a few other modules that handle the complex calculations that are written in a .NET compatible domain-specific language this customer developed themselves. These modules don't support COM, thus the c# wrapper.
The client now needs an operator to be near the hardware to manipulate the robotics. He can either upgrade the hardware, costing him quite a lot but it would give him better remote access which costs about EUR 250.000 to replace the ancient robotics and other hardware or he pays a few developers a tenth of that amount to get his current hardware to do the same. Personally, I think he should not be such a cheapskate but he just wants an estimate what the developers solution would cost him. The code changes aren't big since most of the functionality is already there. It's just combining it all without any TCP/IP communications that makes it more complex.
Basically, the instructions they want to give is to speed things up or slow down, send occasional reports and to send SMS warnings in case of problems. Now, they have an operating sitting next to the screen, drinking coffee all day while reading some newspaper or other magazines. And while that's fun for a few days, he's unable to find someone who wants to do this all the time, 24/7. (Yeah, they work day and night, including weekends.)
Basically, this is all I know myself. Haven't even seen the PC that it needs to be installed on but they have a few configured all in the same way so I can get one to experiment with, once this would be needed. (And it will be a Hell to debug too.)On a final note, I presented the cost estimates and came up with a high enough number to convince my would-be employer to do a hardware upgrade instead. More expensive but it would maintain it's reliability.
Because of this, this Q had just become academic...
Another option would be IKVM. It's a Java implementation for .NET. Please take a look at this related question, the answers there might help you.
JNBridge provides a Java-to-.NET bridge (and vice-versa). It's commecially supported, relatively cheap, and it works well. It's low-latency, and does not require TCP/IP or network communications. You don't need access to the Java code to call it from .NET through the bridge.
Regardless of whether there is any network hardware installed, it is likely that the standalone Windows XP system will still have local TCP/IP networking available. You can have programs listen on a TCP port on the localhost address (127.0.0.1) and other services connect to them to exchange information through any protocol you choose. HTTP with REST might be an appropriate choice.
This is likely to be a lot less painful that trying to integrate all those technologies together in one Franken-program.
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. Hope it will help you.
I am writing an application where all the request to the internet should go from it like in firewall. so that i can block the request for a particular website. In my case the program will be running on the same machine. I have tried the promiscous method but using that we can only capture all the packets comming and going from the machine,
The easiest way to do it is probably to write a Layered Service Provider (LSP). There is an example in the Microsoft SDK on developing LSPs as well. Not as secure as a driver type firewall setup, but a lot easier to implement.
There's "probably" a way to do it with C#, but I have never tried it. Something to look into. If not then just create a native DLL with C/C++ that implements the LSP then have it communicate with your app.
You have to insert your code in the TCP/IP stack, which, if I understand correctly, requires a windows driver.
C# cannot compile native windows drivers, so you'll need to use a library or DLL to implement at least part of your functionality. Look for solutions using C++.
-Adam
A third-party application reads some Java code from an XML file, and runs it when a certain event happens. In Java, I want to tell a .NET 3.5 application, running on the same machine, that this event occurred. The total data transferred each time is probably a few characters.
What is the best way of using Java to tell the .NET process that something happened?
Java doesn't seem to support Named Pipes on Windows, .NET doesn't natively support memory-mapping, and any solution involving web services or RMI is overkill.
If you don't want the full overhead of RMI, you could do direct socket communcation between the two by opening ports and talking to eachother. You'd have to have some way to have both processes agree on which ports to use, how to handshake/etc, but would be simpler than RMI.
ETA: it looks like you can use named pipes from java, you just can't create them? So if the .NET process would create it, you could read/write to it with java. Java just sees it as a file?