¿Por qué no se lanza la excepción de operación de subprocesos al ejecutar exe en bin \ Debug

Question

Estaba depurando una aplicación y en algún lugar del código, un subproceso intenta llegar a un cuadro de lista que fue creado por otro subproceso. Al intentar acceder al cuadro de lista, la aplicación arroja una "Operación entre hilos no válida: control 'cuadro de lista' accedido desde un hilo que no sea el hilo en el que se creó en la excepción" durante la depuración. Sin embargo, cuando ejecuto el resultado de esta aplicación en la carpeta bin \ Debug, no obtengo un diálogo de excepción y puedo ver que se accede al cuadro de lista desde el subproceso no propietario, por lo que creo que hay una diferencia de comportamiento aquí , no solo una excepción suprimida. Puedo conseguir más allá de esta excepción en la depuración con la línea siguiente en el evento Form_Load

Control.CheckForIllegalCrossThreadCalls = false; 

pero lo que es la razón de este comportamiento diferente?

Answer 1

Sí, esto solo se verifica cuando se conecta un depurador. Esto fue necesario porque hubo lotes del código .NET 1.x que infringió esta regla. No es obvio.

El problema más grande es que dicho código se salió con la suya. O bien por suerte, sin pensar demasiado en los ocasionales problemas de pintura o pensando que abortar la aplicación cuando se estancaba y reiniciarla una vez al día era aceptable. Porque el programador no tenía ninguna esperanza real de descubrir el problema sin un diagnóstico.

Microsoft se preocupa mucho por la compatibilidad con versiones anteriores, incluso si es incompatible. La solución es excelente, aunque a veces es incorrecta (Mostrar (propietario) está marcada cuando no debería). Y a veces pasa por alto para verificar cuándo es código en el marco que viola la regla. Lo que sucede cuando la dependencia del hilo es indirecta. Los casos más comunes son la actualización del origen de datos de un control vinculado a datos en un hilo de trabajo (¡Desvincular primero!) Y el uso de un control que escucha el evento SystemEvents.UserPreferenceChanged (¡no cree UI en un segundo hilo!)

---

Para referencia, el código en cuestión está presente en el constructor estático de la clase control:

static Control() 
{ 
    //... 
    checkForIllegalCrossThreadCalls = Debugger.IsAttached; 
    //... 
}