Si vous désassemblez le langage C#, vous verrez souvent des variables temporaires insérées par le compilateur avec des noms tels que :
CS$1$0000Mais qu'est-ce qui les fait apparaître dans les volets Locaux/Auto du débogueur ?
Un de mes collègues essaie de maintenir un outil écrit à l'aide de Rhino ETL . Le débogueur signale que les symboles de son assemblage ont été chargés correctement. Il peut parcourir le code. Mais au lieu d'afficher ses variables dans le débogueur, celui-ci n'affiche que 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 en substituant des classes factices appelées AbstractOperation y Row pour satisfaire le compilateur (ce sont des classes de la bibliothèque ETL de Rhino). Lorsqu'il a essayé cela, en supprimant toutes les dépendances de Rhino ETL, tout est revenu à la normale en termes de visualisation de 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 fonctionné. pas régler le problème. Donc, apparemment, c'est pas en raison d'une incompatibilité de version.
Son code se trouve à l'intérieur d'une méthode itérateur, d'où la nécessité d'une réorganisation importante du code par le compilateur. Mais une méthode itératrice ne casse généralement pas le débogueur !
Dans ce cas, il semble que le débogueur ne fonctionnera pas s'il s'agit d'un override méthode de l'itérateur y la classe de base est AbstractOperation de la bibliothèque ETL de Rhino.
Comment une classe de base peut-elle avoir un tel effet sur le débogueur ?
