Je suis tombé sur un problème si étrange que j'ai enregistré ma session parce que je ne pensais que personne me croire.
Je suis tombé sur un bug qui semble être à un niveau très fondamental. Il s'agit d'une seule application filetée et de tous que je fais est d'évaluer un booléen.
Le booléen est égal à FAUX, cependant, la déclaration de si elle est exécutée comme si elle était vraie ... en quelque sorte. Vous verrez ce que je veux dire. J'ai nettoyé la solution et j'ai reconstruit plusieurs fois. Aucune idée de ce qui se passe.
J'adorerais des explications s'il vous plaît.
6 Réponses :
Je suppose que quelque chose d'étrange se passe au déploiement, de sorte que le PDB est désynchronisé avec le code réel. Si vous utilisez la journalisation au lieu du débogueur pour déterminer ce qui se passe, je soupçonne que vous verrez un comportement plus raisonnable. Je doute que ce soit le CLR lui-même se comportant de manière étrangement bizarre avec un "si" - il est beaucoup plus susceptible d'être une incohérence de débogueur / d'exécution.
J'ai effacé le dossier bin, nous parlons d'une nouvelle construction. J'aime l'idée de mettre dans les déclarations de débogage pour voir ce qui se passe. Je vais essayer cela. Merci Jon.
Deuxièmement que. Débogage de l'application ASP.NET que la mise à niveau de la mise à niveau jette parfois un peu de débogueur. L'exemple le plus simple est que lorsque vous insérez du code dans une méthode, commencez à déboguer et voyez que ces lignes ne sont jamais exécutées - elles sont juste sautées. Ou lorsque le débogueur met en évidence une ligne, mais exécute en réalité le suivant. Supprimer obj / et bin / dossier m'aide toujours.
Je pense que cela ressemble à un cas où les gammes de débogage sont juste éteintes. Vous ne pouvez pas toujours faire confiance à la mise en évidence jaune dans le débogueur. Vous n'êtes pas réellement entrant. Dans les bêtas de F #, nous avons eu beaucoup de bugs comme celui-ci où le point culminant jaune sauterait comme un fou. La mise en évidence du débogueur est principalement à la merci de tout ce que le compilateur écrit dans le fichier .pdb en tant que «gamme source» qui correspond à un ensemble d'instructions compilées particulier.
Quelle version de vs / c # est-ce?
éditer Ayant vu des réponses d'autres, effectivement une cause probable est que votre fichier .PDB est hors de synchronisation avec votre fichier .dll.
Je vais essayer d'éliminer les fichiers OBJ et à tous les autres fichiers temporels et générés lorsque je retourne au travail lundi. Je vais vous garder tous postés.
J'ai vu cela plusieurs fois dans le passé. Fondamentalement, ce qui se passe est que le code que vous déboguez ne correspond pas au code que vous voyez.
Je ne sais pas ce qui cause cela et la solution suit les lignes directrices de Cargo-Cuitre.
J'ai supprimé tous les fichiers du dossier bin, j'ai totalement oublié les fichiers ASP OBJ et les fichiers ASP temporaires. Donnera cela un coup. Je ne comprends toujours pas pourquoi le codage d'un faux génère le résultat souhaité ou pourquoi mettre dans une déclaration d'autre corrige le problème.
Désolé, je devais voter votre réponse, mais il s'avère que toutes ces choses n'ont toujours pas résolu le problème. J'ai supprimé tous les dossiers Bin, le dossier OBJ, tous les fichiers ASP temporaires X86 et X64 et toujours les mêmes problèmes.
Dommage. Faites-moi savoir si vous trouvez une autre réponse.
J'avais exactement le même problème il y a une semaine. Aussi avoir vs2008, dernier SP. Application WinForms. La valeur était fausse mais exécuté sans débogueur compilé comme "libération" était bien. Essayez-le. Je suppose qu'il y a un bogue dans le débogueur VS2008. D'une manière ou d'une autre reproductible avec "si" et "lancer" les mots-clés. EDIT: Le mot "exécuté" ci-dessus est faux de savoir. "Entré mais non exécuté" doit être utilisé à la place. si est toujours exécuté. Je faisais les mêmes enquêtes que dans votre vidéo. Voici mon morceau de code:
L'IF-Block a-t-il été vraiment exécuté ou était-il juste en surbrillance par le débogueur? Dans la vidéo de Vince, il semble que le code n'est pas exécuté (l'objet d'exception E est NULL).
J'ai vu un cas similaire il y a longtemps, à Delphi, alors ma question est la suivante: Compilation de la libération ou du débogage, avec ou sans optimisations?
La raison pour laquelle je demande est une fois, Au cours d'une session de débogage, j'ai découvert une petite procédure composée de 4 à 5 lignes de code que, selon le débogueur, semblait exécuter en sens inverse.
Fondamentalement, avec le type de code suivant: < / p> L'ordre d'exécution, selon le débogueur, était-ce: La raison en était que les lignes étaient la même effet libre entre eux, donc le compilateur "optimisé" le code en le réécrit, en effet réorganisant le code pour s'exécuter complètement en marche arrière. Alors, avez-vous une déclaration de lancer plus poussée En fait, celui-ci se fait exécuter, mais le compilateur montre cela comme celui que vous avez des problèmes, car, en raison de la réorganisation du code, deux déclarations de jeton sont réellement émises une fois en tant que code exécutable? Note : je fais n OT a des raisons de savoir que c'est ce que fait le Studio Visual, mais c'était ce qui s'est venu à mon esprit lors de la vue de votre vidéo.
Il suffit d'ajouter un "moi aussi" ici sur la surbrillance génique du code. Je cours vs2008 avec c #. J'ai un projet Forms Windows faisant référence à une bibliothèque de classe dans un autre projet et je déboguise à la fois ligne par ligne. "À un moment donné", le point culminant jaune de débogage était allant de 14 à 20 lignes de la ligne réelle étant exécutée.
J'ai fermé vs, ouvrit les répertoires pour les deux projets, tout supprimé de bin / debug et obj / débogage dans les deux annuaires, puis redémarré vs. En recompilant et en progressant dans le débogage, tout était encore bien.
Je ne sais pas si le problème était dans une .Manifest, .pdb ou peut-être un fichier .cache. Peu importe. Souffler um tous et ça ira bien.
FWIW, Googling était presque inutile, sauf que cela reviva ce fil. Tous les autres hits concernaient des problèmes avec les modèles VC ++ et VS2005, où un SP corrige ce problème. Ce n'est pas le même problème.
J'ai abandonné ce problème. J'ai tout essayé, j'ai effacé toutes les DLL de fichiers Internet temporaires, tous les fichiers locaux à Bin et même déplacé la solution à un autre PC. Le problème semble être dans le débogueur et je ne sais pas pourquoi.
Quelle version de vs? Avez-vous le dernier service pack de services appliqué?
Pourriez-vous poster l'IL qui est généré pour ce code?
J'ai vu une autre question sur ce même scénario, mais je ne peux pas pour la vie de moi de voir ce que la cause / résolution s'est avérée être.
Question latérale: quel outil avez-vous utilisé pour créer la vidéo? Le framerate avait l'air plus lisse que ce que je gère avec la Camtasia.
Utilisez-vous un outil AOP comme PostSharp qui modifie les assemblages après / dans le cadre de la construction? Avec le temps à partir de vous, le bouton de débogage de votre code commence, cela ne ressemble pas à cela, mais ceux-ci peuvent également dans certains cas, jetez-le dans certains cas le débogueur lorsqu'il s'agit de postes de code exécutable associé aux lignes de code source.