Risolvi DisconnectedContext in Visual Studio

Question

Ho sempre ottenuto un DisconnectedContext (un assistente di debug gestito) quando eseguo la mia applicazione utilizzando Visual Studio. Dato Google e i documenti, questo può accadere quando gli oggetti COM su STA vengono chiamati da un altro thread.

Tuttavia, quando guardo attraverso tutti i thread quando appare il popup, non trovo nulla di simile. (E non trovo nulla di strano).

Alcune idee su come posso trovare il modo in cui viene generato DisconnectedContext?

Answer 1

Questo è un avviso piuttosto serio, non ignorarlo. Lo scenario è che hai creato un oggetto COM su un thread e che il thread è terminato. Ma continui ad usare quell'oggetto. La COM si occupa degli oggetti che si annunciano non thread-safe (ovvero apartment threaded), che effettua automaticamente il marshalling di tutte le chiamate su quell'oggetto al thread che lo ha creato. Questo non può funzionare quando quel thread non è più in giro.

Ignorare l'avviso può produrre errori occasionali e molto difficili da risolvere in caso di problemi di threading. Roba che va sottilmente in errore solo una volta alla settimana. Rivedi il tuo codice, fai attenzione a come l'oggetto che si lamenta è stato creato.

Answer 2

trovato questo mentre cercando la stessa risposta, ho pensato di aggiungere un commento ...

Questo errore è praticamente inevitabile in qualsiasi applicazione multi-threaded con CLR oggetti attraverso in-process Interop (sui filetti transitori). Il problema è che il CLR ha una pulizia non deterministica degli oggetti (che possono essere di RCW, con affinità di thread sugli oggetti COM sottostanti). Non c'è modo di dire al runtime di ripulire gli oggetti creati su un thread (almeno senza creare un altro handle di pulizia non deterministico sul thread); è una limitazione del design del meccanismo di interoperabilità. Detto questo, non c'è modo di uscire in sicurezza da un thread che ha creato oggetti CLR senza ottenere questo errore.

Consiglio migliore: non utilizzare CLR/interop se si può aiutare. Il miglior consiglio successivo: utilizzare COM + per isolare il proprio interop, in modo che CLR possa vivere in un processo che non interrompe mai i thread (utilizzare pool di thread persistenti o equivalente). Il miglior consiglio: unisciti a me per continuare a dire a Microsoft di questo problema a livello di design con il loro interop e speri che lo risolvano.