from :=
Serial Communication with Visual Basic .NET
.............
Unfortunately Microsoft has never paid much attention to the serial port. In the Windows API it is just regarded as a file, and in the first version (1.1) of the .NET framework (managed code) there was no support for serial communication. Fortunately, a new namespace - System.IO.Ports - has been added in version 2.0, which has made things much easier although there are still some problems. For example, it is not possible to control the FIFO in the UART. It is also not possible to tell when the transmitter serial register is empty, so it is almost impossible to control the modem control signals and send a break condition, but worst of all, Microsoft has put an 8 bit wide buffer on top of the 11-bit receiver FIFO and therefore destroyed the possibility for a precise Break, 9th bit and error detection. Besides, many of the examples in the help files are directly misleading and unnecessary complicated. For example, it is recommended to use My.Computer.Ports.OpenSerialPort("COMx") to open a serial port, but if it is done that way, it is not possible to set many of the properties of the port like e.g. the length of the receive buffer and it is not possible to tell when a port is open (IsOpen).
In many developer forums there has been a lot of questions concerning serial port communication, but unless you are lucky enough to get in touch with the one, who has designed the serial port, it is usually very hard to get precise and helpful answers. For example, when we wanted to use very high speed communication (up to 921.6 Kbit/s), we only got the answer that it couldn't be done or we needed to write our own drivers! However, it is in fact possible to use System.IO.Ports even up to 921.6 Kbit/s if a UART with a 128 byte FIFO is used (16C850 or 16C950). As a service to others with the same problems as we have been through we have chosen to publish a small program, which is able to communicate through the serial port. The sample program is written in Visual Basic .NET (in the following just VB), because this language is as close as you get to our own suggestion for a simple and efficient programming language (see: Programming). In .NET there is no longer any performance difference between VB, C++ and C#.
WARNING! This description is based on VS 2005 and .NET 2.0. Unfortunately, SerialPort does not work in all versions of .Net.
To clarify the various .Net releases:
.Net 1.1 RTM = No serial port support!
.Net 2.0 RTM = First version with serial port support.
.Net 3.0 RTM = .Net 2.0 RTM + new .Net 3.0 RTM assemblies.
.Net 3.5 RTM = .Net 2.0 SP1 + .Net 3.0 SP1 + new .Net 3.5 RTM assemblies.
.Net 3.5 SP1 = .Net 2.0 SP2 + .Net 3.0 SP2 + .Net 3.5 SP1 + new .Net 3.5 SP1 assemblies.
Only a few bug fixes were made to Serial Port in .Net 2.0 SP1:
Race condition between SerialPort.Close and event loop runner shutting down Serial IO WaitCommEvent enters high CPU and leaks memory when USB Serial Port removed (Internal Regression).
SerialPort.ReadExisting() returns incorrect characters.
And only one change were made to Serial Port in .Net 2.0 SP2:
UnauthorizedAccessException in SerialStream crashes application after disconnecting device from USB COM port. This should fix the issue of the unhandled exception when disconnecting a device from a USB COM port. However, there are reports indicating that the attempt to fix the bug doesn't work.
The big problem is .Net 3.5 RTM, which includes .Net 2.0 SP1. Almost nothing in SerialPort seems to work in that version! In fact, there seems to be so many errors that .Net 3.5 RTM may be regarded as completely useless for all serial port applications! For the moment the following problems have been reported:
It may crash if you access the modem control signals while the port is receiving.
It may crash if you try to close a port set to a wrong speed - even if you have an error handler for the ErrorReceived event.
You cannot use multiple ports.
In many cases, the DataReceived event does not fire.
If you try to run a 3.5 application generated under Vista on a XP PC, it may lock up the COM ports forever making them useless for all programs including Hyperterminal - even if you delete the application again or remove the 2.0/3.5 framework. It is necessary to repair or re-install Windows to return the ports to their funtionality prior to the loading of the application!
Microsoft thinks that the many problems with serial port in .Net 3.5 RTM may be coursed by other, unrelated(!), bug fixes that went into .Net 2.0 SP1. Most of these problems seems to be fixed in .Net 3.5 SP1, but the problem is that nobody knows what coursed all the problems so nobody knows whether the problems are fixed or not! For the moment it cannot be guaranteed that 3.5 SP1 works as well as 2.0. VS 2008 allow you to select the wanted .NET version when you build your application. This is done in Advanced Compilation Options. Be sure to select either 2.0 or 3.5 SP1!
.......
oh heck lol !
aaarrreeeyyyggg
did wonder why they dropped that seemingly useless app (to non literate people) and one of the most useful for those who work with networks.
Linear Mode
