Actually MSComm isn't a bad component. If your application is quite typical then it's likely that MSComm32 will work just fine - but you're reading this so we're going to assume you have a reason to look for an alternative.
OK, what's wrong with MSComm32 ? Well, the first thing that springs to mind is that MSComm32 is a 32bit OCX. It's not a proper .Net component. Of course you can use an OCX in .Net projects because Interop wraps them to make (usually) 2 DLL files which you deploy to your users. But this strategy is often problematic especiall when building x64 or 'AnyCPU' projects.
Maybe you just want more com ports? As you know, MSComm is limited to 16 ports. Comm64 doesn't have that limitation so it's likely that many people will switch to Comm64 for that reason alone. We've given Comm64 the same syntax as MSComm32 you should be able to drop Comm64 into many existing projects without changing much of your project's source code.
But you may be experiencing other problems. Does any of this sound familiar ?
Applications Hangs - You're sending data but suddenly, for no reason at all, your application appears to lock up. This may only be for a moment but it keeps happening making your application appear unstable. Or maybe it locks up for extended periods or crashes completely forcing you to kill it via task manager.
Data corruption - You're receiving data and all the data is there - it's just mixed up in the wrong order.
Data Loss - In most cases this will be a fault in YOUR programming. MSComm expects you to understand how com ports work and isn't too forgiving. At the slightest opportunity it'll turn round and trash your data. There are however a number of 'features' in MSComm which cause loss of data no matter how good your code is.
Stack Overflow - Now we're going in to too much detail . . . . If you're getting the Stack Overflow error then you have a problem which even good coding might not fix. (Here's a tip - if you're getting Stack Overflow when using MSComm32 then try removing the 'DoEvents' - but if you do that your application becomes unresponsive - you just can't win !)
You can fix many problems with MSComm by knowing a little about how com ports work and making changes to your application. Having said that, there are a number of cases where data loss with MSComm32 is inevitable no matter how good your code is - for example when communicating under strict flow control conditions with slow moving equipment such as manufacturing machinery, robotics etc. MSComm does not like waiting. It gets bored and starts trashing your data.
.... and don't even bother using MSComm32 to do any of that machinery and robotics stuff with com ports attached to remote port servers or thin client terminals
But, even if you could avoid problems with MSComm by changing your code - why should you ? The whole idea of using a ready-made ocx control is that somebody else was supposed to take the time to make a bunch of properties, methods and events allowing you to use com ports without needing to know much about com ports, comTimeOuts and OverlappedIO.
Isn't that what you expect ?