Si vous désassembler C# vous voyez souvent des variables temporaires introduites par le compilateur avec des noms tels que:les variables internes du compilateur apparaissant dans les sections locales du débogueur volet avec Rhino ETL
CS$1$0000
Mais ce qui les faire apparaître dans le débogueur Locaux/volets automatiques?
Un de mes collègues essaie de maintenir un outil écrit en utilisant Rhino ETL. Les symboles de son assembly sont signalés comme correctement chargés par le débogueur. Il peut franchir le code. Mais au lieu d'afficher ses variables dans le débogueur, il affiche uniquement les variables internes générées par le compilateur. Je lui ai suggéré d'essayer d'écrire une nouvelle application console avec le même code et de substituer des classes factices appelées AbstractOperation et pour satisfaire le compilateur (ce sont des classes de la bibliothèque ETL de Rhino). Quand il a essayé cela, en supprimant toutes les dépendances sur Rhino ETL, tout était redevenu normal en termes de voir ses propres variables dans le débogueur.
Il a également essayé de construire Rhino ETL à partir de la source dans la même solution, mais cela n'a pas pas résoudre le problème. Donc, apparemment, c'est pas en raison d'une incompatibilité de version.
Son code est à l'intérieur d'une méthode d'itérateur, d'où la nécessité d'une réorganisation significative du code par le compilateur. Mais une méthode d'itérateur ne casse généralement pas le débogueur!
Dans ce cas, il semble que cela briser le débogueur si elle est une méthode override iterator et la classe de base est AbstractOperation de la bibliothèque Rhino ETL.
Comment une classe de base peut-elle avoir un tel effet sur le débogueur?