Pourquoi le débogueur ne s’arrêterait-il pas à un point d'arrêt dans mon application ASP.NET?
J'essaie de déboguer une grande application ASP.NET.
J'ai défini un point d'arrêt sur la première ligne de Page_Load dans Default.aspx.cs.
Lorsque je lance l'application, mon point d'arrêt se transforme brièvement en contour rond rouge avec une exclamation , puis redevient un point d'arrêt normal. L'application démarre alors sans jamais s'arrêter à mon point d'arrêt .
MSDN me dit que ce symbole signifie "l'emplacement du point d'arrêt n'a pas été chargé". Alors, comment puis-je obtenir l'emplacement du point d'arrêt à charger? Il travaillait il y a quelques semaines. Quels types de choses pourraient causer un point d'arrêt "ne pas être chargé"?
Que puis-je faire pour que le débogueur s'arrête à nouveau à mes points d'arrêt?
Addenda:
Je n'arrive toujours pas à faire fonctionner le débogage en appuyant sur F5, mais je peux démarrer le site Web, puis lancer le processus de débogage/attachement pour passer en mode de débogage. Si quelqu'un sait pourquoi cela fonctionnerait, mais quand j'appuierais sur F5, cela ne fonctionnerait pas (les boutons de débogage n'apparaissent même pas sur F5), toute idée serait la bienvenue.
Essayez de reconstruire complètement l'application. Faites attention que c'est dans la configuration "Debug".
Autant que je sache (mais je ne suis pas un expert dans ce domaine), cela peut se produire lorsque les fichiers d’informations de débogage (.PDB) ne sont pas synchronisés avec les éléments réellement compilés.
Gens .... J'ai trouvé une autre solution pour le point d'arrêt ne vous arrêtez pas .. Dans la fenêtre Attacher au processus sous Visual Studio 2010 et à l'aide de Framework 3.5, détermine automatiquement les types de code à déboguer (v2.0, v1.1, v1 .0) et (v4.0).
Visual Studio est confus et détermine parfois automatiquement le code géré 2.0 en tant que code géré 4.0.
Dans ce cas, vous devez cliquer dans le bouton "Sélectionner ..." sur le champ "Joindre à" et sélectionner Gérer (v2.0, v1.1, v1.0).
Cordialement
Problème de débogage VS avec IE8
Comme il s’agit de mon premier article sur Weblogs, j’ai décidé de parler d’un problème qui a été ouvert fréquemment sur le forum officiel ASP.NET, c’est le débogueur de VS qui tombe en panne avec IE8.
J'avais répondu au même problème 4 fois, j'espère donc que quelqu'un trouvera ce post très utile s'il est confronté au même problème.
Comment le débogueur VS peut-il tomber en panne avec IE8?
Si vous avez ouvert plusieurs instances de IE8 et que vous tentez de déboguer votre projet, vous aurez principalement le problème suivant: le débogueur de VS s'arrête et ignore vos points d'arrêt!
Pourquoi était-ce?
Internet Explorer 8 intègre une fonctionnalité appelée Internet Explorer faiblement couplée (LCIE) qui permet à IE de s'exécuter sur plusieurs processus . http://www.Microsoft.com/windows/internet-Explorer/beta/ readiness/developers-existing.aspx # lcie
Les anciennes versions du débogueur Visual Studio sont gênées par cela et ne peuvent pas comprendre comment se connecter au processus correct.
Pour résoudre ce problème, vous devez désactiver la fonctionnalité de croissance du processus du LCIE en procédant comme suit:
1) Ouvrez RegEdit 2) Accédez à HKEY_LOCALMACHINE -> LOGICIEL -> Microsoft -> Internet Explorer -> Principal 3) Ajoutez un mot-clé sous cette clé, appelé TabProcGrowth 4) Définissez TabProcGrowth sur 0
Si vous rencontrez le même problème sous Vista ou plus récent, vous devrez également désactiver le mode protégé.
Et puis allez-y et commencez à déboguer votre code :)
Si vous utilisez Visual Studio 2005 et IE8, j'ai peut-être une explication: IE8 a introduit une nouvelle fonctionnalité appelée Loose-Coupled IE (LCIE) qui provoque des problèmes connus lors du débogage d'applications ASP.NET VS2005. Voir ce thread sur SO pour plus de détails et des solutions.
Il s'est avéré que tous mes problèmes de débogage ont disparu lorsque j'ai fermé toutes les instances en cours d'exécution d'IE8 avant de démarrer une exécution de débogage dans mon projet ASP.NET.
Une autre raison pour laquelle je poste ici est de partager un blog que j'ai trouvé qui répertorie un grand nombre de solutions potentielles au problème «les points d'arrêt ne fonctionnent pas». C'est sympa car le blog répertorie à un endroit la plupart des solutions que j'ai trouvées éparpillées sur Internet. Quoi qu'il en soit, l'auteur du blog est George P. Alexander; Je vais copier et coller les parties juteuses ici au cas où quelque chose arrive à l'article:
Utilisation de missiles guidés de précision: Supprimez les fichiers .pdb de vos obj et dossiers bin. Recompiler. Courir.
Carpet bomb all .dlls: Supprimez et rechargez tous les .dlls référencés (comme Vos projets de classe)
Libérer un WMD: Si les n ° 1 et n ° 2 ne fonctionnent pas, supprimez le contenu du très obj et les dossiers bin lui-même pour que tous les fichiers .pdbs et .dll sont annihilés . Rechargez le fichier .dll requis et donnez-le un coup de feu.
Magie VS.Net: Fermez VS.Net et redémarrez. Reconstruire. Courir. Oui il parfois ça marche.
Magie Windows: arrêtez votre ordinateur et redémarrez. Reconstruire. Courir.
Mode d'exécution: assurez-vous que le mode d'exécution VS.Net est défini sur "Debug" et non "Release"
Paramètres Web.config: assurez-vous que la balise "compilation" de l'élément XML est dans votre fichier web.config a un attribut avec debug = "true". Seulement si c'est activé les applications et services Web ont leurs fichiers .pdb générés avec les .dll
Propriétés du projet n ° 1: Assurez-vous que Propriétés du projet -> Débogage -> Activez "Le débogage ASP.Net est vrai" ou "Activer le processus d'hébergement Visual Studio " (Selon la version de VS.Net que vous utilisez).
Propriétés du projet n ° 2: Assurez-vous que Propriétés du projet -> Propriétés de configuration -> Construire -> "Générer des informations de débogage" est réglé sur "True".
Mauvais processus attaché: Votre session de débogage peut ne pas être attachée au bon processus. Vous devrez peut-être pas à pas pour attacher manuellement le fichier processus. C'est possible avec Web Prestations de service. L'option d'attacher un processus est dans le menu de débogage.
Débogage de script et de code non managé: impossible de déboguer des scripts ou code non géré? Assurez-vous que ce projet Propriétés -> Débogage -> "Activer ASP Débogage" ou "Activer Unmanaged Débogage" (selon votre version De VS.Net) est défini sur true.
Directive @Page n ° 1: assurez-vous que l'attribut AutoEventWireup dans votre fichier Ensemble de directives @Page du document .aspx à "vrai".
Directive @Page # 2: Assurez-vous que l'attribut Debug dans votre .aspx directive @Page du document définie sur "vrai". Si vous ne trouvez pas le attribut, ça va. Par défaut c'est vrai.
Rogue .DLL: Assurez-vous de ne pas avoir d’autre instance du fichier .dll courir qui se trouve ailleurs d'où votre chemin projet prévu.
14.1 Cellule de veille n ° 1 du fichier .dlls: Avez-vous installé votre projet .dll dans le fichier Dossier GAC? Vous pourriez exécuter le .dll hébergé dans votre dossier GAC à la place de celui dans votre dossier bin . Supprimer/désinstaller le fichier .dll du GAC et puis réessayez.
14.2 Cellule dormante n ° 2 du fichier .DLL:
C:\Documents et Paramètres [Nom d'utilisateur]\VSWebCache [Machine Prénom]:
Libérez un WMD (# 3) sur les dossiers qui sont liés à votre projet.
14.3 Cellule de couchage DLL n ° 3: les fichiers .dll de votre projet qui reposent ailleurs où mais sont plutôt référencés dans votre projet. Vous pouvez les trouver en examinant les propriétés du projet. Dans Bref, VS.Net fait référence à un autre .dll et pas celui chargé dans votre environnement dev.
14.4 Cellule de sommeil n ° 4 de la bibliothèque .DLL: Espérons que vous n’ayez pas à jouer avec ce dossier au moment où vous avez terminé avec les points ci-dessus ...Présentation de C:\WINDOWS\Microsoft.NET\Framework [.Net version]\Fichiers ASP.NET temporaires \.
Ce dossier pourrait contenir un fichier plus ancien versions de .dll stockées dans votre Dossier Windows qui pourrait recevoir référencé lors de l'exécution de VS.Net . Si cela se produit, ça craint. Vous pouvez supprimer autant de dossiers et de contenus que vous pouvez répondre à votre projet . Il pourrait y avoir des verrous en lecture seule qui vous auriez besoin de désactiver en fermant processus. Ceci est plus d'un dernier effort de fossé. Ne faites pas cela si vous avez jamais joué avec votre Windows dossier. Dans la plupart des cas, quelque chose est fait ci-dessus avant ce point fait habituellement répare le. Donc, idéalement, vous n'avez pas à lisez ce point au moment où vous êtes fait avec les pointeurs ci-dessus. Et juste pour mémoire, je ne recommande pas quiconque d’explorer cette option ou de jouer autour de votre dossier Windows si vous ne pas avoir de doctorat en physique, Mathématiques, Windows et .Net.
Autres astuces:.
Avez-vous défini <compilation debug="true"> dans votre web.config?
Vous pouvez également essayer ce qui suit:
- Fermez la solution et visual studio.
- Exécuter iisreset/stop
- Supprimez tout sous C:\windows\Microsoft.net\framework\v2.0.50727\Fichiers ASP.NET temporaires. Si vous rencontrez des problèmes lors de la suppression de certains de ces fichiers, il est possible qu'une version de Visual Studio ou son débogueur soit toujours en cours d'exécution.
- Exécuter iisreset/start
- Ouvrez la solution dans VS
- Définissez la construction sur Debug
- Exécuter tout reconstruire au niveau de la solution
- Hit F5
J'avais un problème similaire avec les points d'arrêt qui ne fonctionnaient pas et, en même temps, dans la console IIS, je ne pouvais pas éditer la configuration de mon projet, c'est-à-dire que le bouton Modifier la configuration était grisé.
[Pour trouver le bouton Edit Configuration: Start | Tous les programmes | Outils d'administration | Internet Information Services, puis développez l’ordinateur requis, développez Sites Web, développez Site Web par défaut, localisez le projet souhaité, cliquez dessus avec le bouton droit de la souris, sélectionnez Propriétés, puis l'onglet ASP.Net.]
J'ai découvert que dans IIS, la version ASP.Net de mon projet était définie sur 4.0.30319. Une fois que je l'ai défini sur 2.0.50727 , le bouton Modifier la configuration est devenu disponible (cliquable) et mes points d'arrêt ont à nouveau fonctionné.
J'ai également compris qu'il serait peut-être intéressant de vérifier la version ASP.Net définie dans IIS pour "Site Web par défaut" [dans la console IIS, développer Sites Web, cliquer avec le bouton droit de la souris sur Site Web par défaut et sélectionnez Propriétés puis l'onglet ASP.Net], de sorte que tout nouveau projet créé dans Visual Studio acquière le paramètre Site Web par défaut.
J'ai eu ce problème récemment (WinXP, VS2003) et j'ai essayé plusieurs des solutions ci-dessus sans succès. Ensuite, je me suis rendu compte que plusieurs versions du runtime .Net étaient installées . Alors, j’ai évoqué IIS 5.1, localisé le dossier virtuel approprié, entré dans les propriétés, puis dans l’onglet ASP.NET, puis modifié. la version ASP.NET à partir de 4.? à 1.1, et il est apparu que cela résolvait le problème. Il se pourrait que la solution soit la suivante, PLUS une ou plusieurs des choses ci-dessus.
En outre, tout ce qui précède constitue un "évier de cuisine" composé de différentes choses à essayer. C'est comme si vous jetiez un paquet de nouilles spaghettis contre le mur, en espérant que certaines d'entre elles resteraient collées… .. Et, certaines de ces «solutions» pourraient causer d'autres problèmes dans votre programme. Par exemple, la suggestion de définir AutoEventWireup = "true" peut provoquer le déclenchement de certains de vos événements deux fois! (voir http://support.Microsoft.com/kb/814745 ).
Recherchez toujours Configurations de la solution à définir comme "Débogage" pour le débogage . Il est possible que la configuration de la version finale soit publiée après la publication.
Dans mon cas, le problème finit par être lié à l'utilisation à la fois de full IIS (non Express) et d'une version de débogage contenant des symboles de débogage complets, mais contenant également les propriétés du projet, Build, Optimize code vérifiées.
Sous Express, cela fonctionne bien, mais sous Full IIS, cela ne fonctionne pas. Visual Studio se connecte correctement au processus w3wp, mais ne charge pas les symboles de la DLL optimisée. Dans Visual Studio, vous pouvez accéder à Debug, Windows, Modules, puis rechercher la DLL spécifique et voir si, dans la colonne Symbol Status, il affiche Skipped Loading Symbols.. Faites un clic droit dessus et sélectionnez Load Symbols pour le faire fonctionner.
Un paramètre supplémentaire susceptible d'avoir une incidence sur ce point est que Visual Studio est défini sur un code utilisateur de débogage sous Debug, Options and Settings, Debugging, General, Enable Just My Code. Une fois optimisées, les dll seront marquées comme pas du code utilisateur lorsqu’elles fonctionneront sous IIS complet. Ainsi, lorsque Just My Code est activé, tous les points d’arrêt qu’ils contiennent sont ignorés. Vous pouvez soit configurer VS pour déboguer du code non utilisateur, soit définir la construction pour ne pas optimiser afin d'autoriser l'atteinte des points d'arrêt.
- Accédez aux propriétés de votre solution.
- Dans les propriétés de configuration, définissez le jeu de configuration de génération sur "Debug" au lieu de "release" pour tous les projets de votre solution.
- Cliquez sur Appliquer puis sur le bouton OK.
Cela m’a rendu fou pendant une semaine, jusqu’à ce que j’ai enfin remarqué qu’il manquait un paramètre . Cela répond à la réponse de Jay Riggs, mais pour Visual Studios 2010 au lieu de 2005 . le débogueur ASP.NET est vérifié.
Pour moi, les propriétés du projet avaient été réinitialisées par un autre développeur pour utiliser IIS Express et non mon local IIS avec. Le projet a donc bien fonctionné, mais rien n’a été touché.
Faites un clic droit sur Projet> Propriétés> Web> Serveurs - passez à IIS local . Je sais que cela ne fonctionnera pas pour tout le monde, mais espère que cela aidera quelqu'un.