Solución:
Llamar a SerialPort.Close () con frecuencia es un error. Tener otra aplicación que le robe el puerto no es exactamente muy deseable. Pero lo más problemático, y el problema que está teniendo, es que Close () no espera a que salga un hilo de trabajo iniciado por SerialPort. Ese hilo de trabajo genera los eventos DataReceived, PinChanged y ErrorReceived. Tarda “un poco” en salir, podría ser entre milisegundos y segundos. Llamar a Open () nuevamente fallará hasta que se haga.
Es una falla en la clase, pero inducida por el uso común de puertos seriales. Las aplicaciones normalmente no las cierran hasta que finaliza la aplicación. Incluyendo nunca, evitando un escenario de punto muerto común. Tenga en cuenta que el artículo de MSDN para Close advierte sobre esto:
La mejor práctica para cualquier aplicación es esperar un tiempo después de llamar al método Close antes de intentar llamar al método Open, ya que es posible que el puerto no se cierre instantáneamente.
Si está preocupado por la apertura / cierre y otras aplicaciones que roban el puerto COM, puede usar el enfoque utilizado por Microsoft para el controlador intermedio GPS en Windows integrado, es decir, escribir un agregador, uno que abre el puerto, lo mantiene abierto, luego proporciona puntos de conexión para que otras aplicaciones se conecten.
La forma de crear las conexiones depende de usted: puede profundizar en el hardware y escribir un controlador de puerto de comunicación virtual que se pueda compartir, o puede hacer lo que hice yo y escribir un servicio de socket win32 simple que permita que los programas cliente se conecten a través de Conexiones de enchufe de Windows regulares.
Tal vez no sea una respuesta sencilla, pero es un tema de reflexión.