Resolver DisconnectedContext en Visual Studio

Question

Siempre obtuve un DisconnectedContext (un asistente de depuración administrado) cuando ejecuto mi aplicación usando Visual Studio. Dado Google y documentos, esto puede suceder cuando se llaman objetos COM en STA desde otro hilo.

Sin embargo, cuando miro a través de todos los hilos cuando aparece la ventana emergente, no encuentro nada como esto. (Y no encuentro nada extraño en absoluto).

Algunas ideas sobre cómo puedo encontrar la forma en que se plantea DisconnectedContext?

Answer 1

Esta es una advertencia bastante seria, no la ignore. El escenario es que creó un objeto COM en un hilo y ese hilo salió. Pero sigues usando ese objeto. COM se encarga de los objetos que anuncian que no son seguros para subprocesos (también conocido como apartamento enhebrado), clasifica automáticamente cualquier llamada en ese objeto al subproceso que lo creó. Eso no puede funcionar cuando ese hilo ya no está alrededor.

Ignorar la advertencia puede ocasionalmente ocasionar problemas en la resolución de errores de carrera. Cosas que sutilmente mal solo una vez a la semana. Revise su código, preste atención a cómo se creó el objeto sobre el que se queja.

Answer 2

encontrado esta en la búsqueda de la misma respuesta, que me gustaría añadir un comentario ...

Este error es prácticamente inevitable en cualquier aplicación multi-hilo usando objetos CLR a través de procesos de interoperabilidad (en las roscas transitorios) El problema es que el CLR tenía limpieza no determinista de objetos (que pueden ser RCW, con afinidad de hilos en los objetos COM subyacentes). No hay forma de que pueda decirle al tiempo de ejecución que limpie los objetos creados en un subproceso (al menos sin crear otro identificador de limpieza no determinista en el subproceso); es una limitación de diseño del mecanismo de interoperabilidad. Teniendo en cuenta eso, no hay forma de salir de manera segura de un hilo que haya creado algún objeto CLR sin potencialmente obtener este error.

Mejor consejo: no use CLR/interoperabilidad si puede evitarlo. El siguiente mejor consejo: utilice COM + para aislar el proceso de su interoperabilidad, de modo que el CLR pueda vivir en un proceso que nunca finalice los subprocesos (use un grupo de subprocesos persistentes o equivalente). El siguiente mejor consejo: únete a mí para seguir contando a Microsoft sobre este problema de nivel de diseño con su interoperabilidad, y espero que lo solucionen.