PaulS:
You have some proof of that? I have NEVER had an issue with it. I do a LOT of network apps at work and at home.
Yeah. The most obnoxious of these are (IMO) the IOException-on-Close() bug, and the ObjectDisposedException bug. Both are blogged about extensively and widely reported on many forums, including Microsoft's own forums. Here are a couple of useful blogs with suggested workarounds:
The latter is also widely reported (citation: Google results for SerialPort + ObjectDisposedException)
Here's a useful thread on the MSDN forums that goes into a workaround for that one (the GC.SuppressFinalize() workaround is one of the most popular, though I've found it's still less than 100% successful at rejecting uncatchable exceptions due to surprise removals):
https://social.msdn.microsoft.com/Forums/en-US/0e4894cd-76db-4101-8cfc-7b7f13c1489a/serialport-objectdisposedexception?forum=netfxbcl
Here's a good blog with some suggestions for a number of other SerialPort bugs/design flaws, although the thrust of the blog is really, "stay away from this class":
Not exactly encouraging!
So there are a few. Other sharp edges include the need to sleep between Close() and Open() on the same object or with the same port, and the fact that calling Close() from a UI thread on shutdown can lead to a deadlock. The former is actually called out in the documentation, although it's embarrassing vague:
Microsoft:
"The best practice for any application is to wait for some amount of time after calling the Close method before attempting to call the Open method, as the port may not be closed instantly."
(Not surprisingly, when you look at SerialPort code others have written, you'll see that everybody picks a different amount of time. )
In short: It's difficult to use SerialPort well, and even using it well doesn't guarantee success. There are reliability issues that require the consumer to implement silly workarounds like inhibiting garbage collection. They haven't been fixed by Microsoft, nor have any of the workarounds been officially blessed (as far as I can tell). Mostly I suspect Microsoft just doesn't have a lot of time to devote to improving legacy serial support.
After wrestling with the above issues, as well as wrestling with the general annoyance of having my Windows app try to figure out what COM port my Arduino was plugged into, I realized that wresting with legacy serial just wasn't necessary. It's so easy not to, in fact. Just get any clone with an FT232 on it and use the D2XX C# wrapper FTDI provides. Then you can flash proper names/descriptions onto your devices and enumerate/open them by name. After you've gone there, you'll never want to mess with SerialPort and its myriad headaches again.