Pourquoi le débogueur pas s'arrêter à un point d'arrêt dans mon ASP.NET application?

Je suis en train de déboguer un grand ASP.NET application.

J'ai mis un point d'arrêt sur la première ligne dans le Page_Load en Défaut.aspx.cs.

Lors du démarrage de l'application, mon point d'arrêt tourne brièvement dans un rond rouge contour avec un point d'exclamation dans il, se transforme ensuite en un point d'arrêt, puis le application démarre sans jamais s'arrêter, à mon point d'arrêt.

MSDN me dit que ce symbole signifie "le point d'arrêt n'a pas été chargé". Alors, comment puis-je obtenir le point d'arrêt à charge? Il a travaillé il y a quelques semaines. Quelles sortes de choses pourraient entraîner un point d'arrêt pour "ne pas être chargé"?

Que puis-je faire pour que le débogueur s'arrête à mes points d'arrêt de nouveau?

Addendum:

Je ne peux toujours pas le débogage pour travailler en appuyant sur F5, mais je peux commencer le site web, puis faire debug/fixez-le processus pour obtenir en mode de débogage. Si quelqu'un sait pourquoi cela pourrait fonctionner, mais lorsque j'appuie sur F5, cela ne fonctionnerait pas (le débogage des boutons ne s'affiche même pas sur F5), toutes les idées seront les bienvenues.

Dans mon cas, le même ASP.NET app fonctionne sur plusieurs domaines et utilise le domaine de la demande de choisir le contenu de servir. Il est configuré pour s'exécuter sur IIS local et via le fichier hosts, les domaines sont résolus à l'adresse 127.0.0.1. L'application a couru OK, mais le débogueur ne pas s'arrêter sur des points d'arrêt jusqu'à ce que je définir les propriétés du projet > Web > Serveur > Projet d'Url pour le domaine utilisé pour faire la demande. (Il contenait un autre domaine que le domaine d'application est disponible sous.)

InformationsquelleAutor Edward Tanguay | 2009-05-13

asp.net debugging

48

Essayer de faire une reconstruction complète de l'application. Attention, il est en "Debug" de configuration.

Comme je le comprends (mais je ne suis pas un expert en ces choses), cela peut se produire lorsque les informations de débogage des fichiers (.APB) sont en décalage avec le réel compilé chose.
- J'ai supprimé tous les .fichiers pdb dans le ../debug/bin, mais cela n'a pas aidé.
- La suppression n'est pas la chose. Vous devez les recréer. Avez-vous essayé de "régénérer la Solution" dans Visual Studio?
- Fou de moi, j'ai eu l'option de compilation à la sortie, pas de débogage!
- Doh! J'ai eu le système de Libération plutôt que de Debug. Merci pour le heads-up pour vérifier la chose la plus évidente de la première!
- La Reconstruction fonctionne pour moi, mais parfois je dois faire Nettoyer d'abord et puis une Reconstruction.
- Juste une simple reconstruction résolu le problème pour moi. Merci!
InformationsquelleAutor Vilx-
17

Les gens.... J'ai trouvé d'autres solution pour le point d'arrêt dont stop.
Dans l'Attacher à la fenêtre de ce Processus sur Visual Studio 2010 et à l'aide de Framework 3.5, par défaut détermine automatiquement les types de code de debug (v2.0, v1.1, v1.0) et (v4.0).

Visual Studio devient confus et détermine automatiquement 2.0 géré code 4.0 code managé parfois.

Dans ce cas, vous devez cliquez sur "Sélectionner..." bouton "Attacher" et sélectionnez Gérer (v2.0, v1.1, v1.0).

Ce qui concerne
- Bien whad shinya savoir. En fait, cela a fonctionné pour moi. =) Merci man! (+1)
- Mazzoni Pierzynski Seul code dans les fichiers CS est d'être frappé et pas de code Java script. Dans Le sélectionnez le code type de la fenêtre, j'ai essayé de vérifier à la fois Géré(4.0) et le Script cependant Visual studio ne permet pas. Il est dit "SCript debuggiing n'est pas compatible avec la gestion(v4.0). Aimeriez-vous décochez la case Géré(v4.0) ? "Toutes les idées comment résoudre ce problème?
- Merci beaucoup! Cela a été un problème pour moi. Je suppose en raison de la projets erreurs de configuration, le débogueur ne pouvait pas déterminer correctement le bon type de code, jusqu'à ce que j'ai sélectionné manuellement le .Version NET ET les autres "Géré Mode de Compatibilité".
InformationsquelleAutor Augusto Mazzoni Pierzynski
6

VS Debug Problème avec IE8

Comme c'est mon premier post sur les Blogs, j'ai décidé d'écrire à propos d'un problème qui a été ouvert fréquemment sur le ASP.NET forum officiel qui est la VS débogueur se bloque avec IE8.

J'avais répondu le même problème que 4 fois, donc j'espère que quelqu'un va trouver ce post très utile si il est face au même problème.

Comment le VS débogueur de collision avec IE8?

Si vous avez ouvert plusieurs instances de IE8 et vous essayez de déboguer votre projet, vous aurez la plupart du problème où le VS débogueur s'arrête juste et ignore vos points de rupture!

Pourquoi?

IE 8 a une fonctionnalité appelée Loosely-Coupled Internet Explorer (LCIE) dont les résultats dans IE cours d'exécution à travers de multiples processus.
http://www.microsoft.com/windows/internet-explorer/beta/readiness/developers-existing.aspx#lcie

Des versions plus anciennes de le Débogueur Visual Studio se confondre par ce et ne peut pas comprendre comment attacher le processus correct.

Pour surmonter ce problème, vous devez désactiver le processus de croissance de la fonctionnalité du LCIE en suivant les étapes ci-dessous:

1) Ouvrez RegEdit
2) accédez à HKEY_LOCALMACHINE -> LOGICIELS> Microsoft -> Internet Explorer -> Principal
3) Ajoutez une valeur dword sous cette clé, appelé TabProcGrowth
4) Définir TabProcGrowth à 0

Si vous rencontrez le même problème sur Vista ou plus récent, vous aurez également besoin de désactiver le mode protégé.

Et puis aller de l'avant et commencer à déboguer votre code 🙂

InformationsquelleAutor madhusudhan.K
4

Si vous utilisez Visual Studio 2005 et IE8 je pourrais avoir une explication: IE8 a introduit une nouvelle fonctionnalité appelée Loosely-Coupled IE (LCIE) qui provoque des problèmes connus lors du débogage de VS2005 ASP.NET des applications. Voir ce fil sur de SORTE pour plus de détails et quelques solutions.

Il s'est avéré que tous mes problèmes de débogage a disparu lorsque j'ai arrêté toutes les instances en cours d'exécution de IE8 avant, j'ai commencé un débogage exécuter dans mon ASP.NET projet.

Une autre raison pour laquelle je vais poster ici est de partager un blog que j'ai trouvé qui répertorie un grand nombre de solutions potentielles pour les " points d'arrêt ne fonctionne pas problème. C'est agréable parce que le blog de listes dans un endroit que la plupart des solutions que j'ai trouvées dispersées sur l'Internet. De toute façon l'auteur du blog est George P. Alexandre; je vais copier et coller le juteux pièces ici, dans le cas où quelque chose arrive à l'article:
1. De précision à l'aide de missiles guidés: Supprimer les .fichiers pdb dans votre obj et
  bin dossiers. Recompiler. Exécutez.
2. Tapis de bombe .dll: Supprimer et de le recharger tous les référencée .dll (Comme
  vos projets de classe)
3. La libération d'un ADM: Si #1 & #2 ne fonctionne pas, supprimez le contenu de la très
  obj et bin dossiers, de sorte que
  tous les .pdb et .les dll sont anéanties.
  Recharger le .dll requis et de le donner
  un coup de feu.
4. VS.Net magie: Close VS.Net et redémarrer. Reconstruire. Exécuter. Oui, c'
  parfois ne fonctionne pas.
5. Windows magie: éteindre votre ordinateur et redémarrez-le. Reconstruire. Exécuter.
6. Mode d'exécution: assurez-vous que VS.Net mode d'exécution est fixé à
  "Debug" et non pas "Libération"
7. Web.paramètres de configuration: assurez-vous que l'Élément XML "compilation" de la balise dans
  votre web.fichier de configuration est un attribut
  avec debug = "true". Seulement si c'est
  est activée, les applications web et les services
  ont leur .pdb fichiers générés avec
  l' .dll
8. Propriétés du projet #1: assurez-vous que les Propriétés de Projet --> Debug -->
  Activer "ASP.Net le Débogage est vrai" ou
  "Permettre à l'Hébergement Visual Studio
  Le processus" (selon la version de
  VS.Net vous utilisez).
9. Propriétés du projet n ° 2: assurez-vous que les Propriétés de Projet -->
  Propriétés de Configuration --> Build -->
  "Générer des Informations de Débogage" est
  la valeur "True".
10. Mauvais processus de rattachement: Votre session de débogage peut ne pas être attaché
  pour le bon processus. Vous pourriez avoir à
  step-in pour connecter manuellement le
  processus. C'est possible avec le Web
  Services. La possibilité de joindre un
  le processus est dans le menu déboguer.
11. Script et non code de débogage: vous ne Pouvez pas déboguer des scripts ou
  code non managé? Assurez-vous que le Projet
  Propriétés --> Debug --> "Activer ASP
  Débogage" ou "Activer non géré
  Débogage" (selon votre version
  de VS.Net) est définie sur true.
12. Directive@Page #1: assurez-vous que l'attribut AutoEventWireup dans votre
  .aspx document de la directive @Page jeu
  à "true".
13. Directive@Page #2: assurez-vous que l'attribut de Débogage dans votre .aspx
  document de la directive @Page définie à
  le "vrai". Si vous ne trouvez pas la
  attribut, c'est correct. Par défaut, il est
  vrai.
14. Voyous .Dll: assurez-vous que vous n'avez pas d'autre exemple de l' .dll
  l'exécution de ce qui se trouve ailleurs à partir de
  votre chemin de Projet.
14.1 Voyous .dll sleeper cell #1: Avez-vous l'installation de votre projet .dll dans le
GAC dossier? Vous pourriez être en cours d'exécution de la
.dll hébergé dans votre GAC dossier à la place
de l'un dans le dossier bin.
Supprimer/Désinstaller l' .dll dans le GAC
et puis essayez à nouveau.

14.2 Voyous .Dll sleeper cell #2:

C:\Documents et
Réglages[Nom D'Utilisateur]\VSWebCache[Machine
Nom]:

Libérer une ADM (#3) sur les dossiers
sont liées à votre projet.

14.3 Voyous Dll sleeper cell #3: .dll à partir de votre projet qui sont couchées d'autre
où, mais sont plutôt référencé dans
votre projet. Vous pouvez trouver ces
en examinant les propriétés du projet. Dans
bref, VS.Net fait référence à certains autres
.dll et non pas celui chargé dans votre
environnement de dev.

14.4 Voyous .Dll sleeper cell #4: j'espère que vous n'aurez pas à jouer avec
ce dossier par le temps que vous avez terminé
avec les points ci-dessus...

L'introduction de
C:\WINDOWS\Microsoft.NET\Framework[.Net
version]\Temporary ASP.NET Files\

Ce dossier peut contenir plus âgés
les versions de .dll stockées dans votre
Dossier de Windows qui pourraient être
référencé lors de l'exécution de VS.Net.
Si cela arrive, elle le suce. Vous pouvez
supprimer autant de dossiers et de contenu
vous pouvez RELATIVES À VOTRE PROJET.
Il peut être en lecture seule serrures
vous devez désactiver par la fermeture de
les processus. Ce n'est plus un dernier
effort de fossé. Ne pas le faire si vous avez
jamais joué autour avec votre Windows
dossier. Dans la plupart des cas, quelque chose de fait
ci-dessus avant de ce point, habituellement, ne
fix it. Donc, idéalement, vous n'avez pas à
lire ce point, par le temps que vous êtes
fait avec les pointeurs. Et juste
pour le record, je ne recommande pas
personne à explorer cette option ou jouer
autour avec votre dossier Windows si vous
ne pas avoir un Doctorat en Physique,
Les mathématiques, Windows et .Net.

Autres conseils:
1. Fenêtre du Module: Le module de fenêtre peut être consulté pendant que votre application
  est en cours d'exécution à partir de VS.Net (Debug -->
  Windows --> les Modules). Tous les modules de
  votre projet devrait y figurer.
  Si votre projet .dll est répertorié et
  le statut de la signification des Symboles est "Symboles
  Chargé", vous avez pas de problème.
Si c'est un message de votre .apb
fichier, goto "Sélectionnez les Symboles" et le
approprié .fichier pdb. Vous pourriez avoir
pour redémarrer le débogage ou de la charge VS.Net
de nouveau. L'état doit maintenant changer
de "Chargé des Symboles".

2. VS.Net Options: Outil --> Options - > le Débogage VS.Net à partir de 2005, il y a encore un nœud appelé
"Symboles" où vous pouvez poser des VS.Net pour
recherchez les symboles. Ce peut être consulté
par la Fenêtre du Module lors du débogage
trop.
InformationsquelleAutor Jay Riggs
4

Vous pouvez également essayer les suivantes:
1. Proche de la solution et visual studio.
2. Exécuter la commande iisreset /arrêt
3. Supprimer tout sous C:\windows\microsoft.net\framework\v2.0.50727\Temporary ASP.NET les Fichiers. Si vous avez des problèmes avec la suppression de certains de ces fichiers, vous pouvez avoir une version de visual studio ou c'est débogueur toujours en cours d'exécution.
4. Exécuter la commande iisreset /début
5. L'ouverture de la solution dans VS
6. La valeur build Debug
7. Exécuter tout Reconstruire au niveau de la solution
8. Appuyez Sur La Touche F5
- J'ai tout fait sur cette liste (même si je ne suis pas exécutant IIS local, mais au lieu de localhost/port du serveur), mais j'ai toujours le problème. J'ai supprimé tous .fichiers pdb, pas de changement. La configuration de la compilation de tous ces projets est "debug".
- Peut-être essayer de le faire tourner sous IIS.
- Cela a fonctionné pour moi, bien que le dossier a été v4.0 au lieu de V2.0
InformationsquelleAutor Jonathan Parker
3

Avez-vous mis <compilation debug="true"> dans votre site web.config?
- oui, dans mon web.config j'ai: <compilation debug="true" defaultLanguage="c#">
InformationsquelleAutor Miha Markic
2

J'ai eu un problème similaire avec des points d'arrêt qui ne travaillent pas et, dans le même temps, dans la Console IIS, je n'étais pas en mesure de modifier la configuration pour mon projet, c'est à dire la modification de la Configuration du bouton est grisé.

[Pour en savoir la modification de la Configuration du bouton: Démarrer | Tous les Programmes | Outils d'Administration | Services Internet, puis développez l'ordinateur, développez Sites Web, développez Site Web par Défaut, recherchez et cliquez droit sur votre projet, sélectionnez Propriétés puis l'ASP.Net onglet.]

J'ai découvert que dans IIS, le ASP.Net version pour mon projet a été mis à 4.0.30319. Une fois que j'ai définir 2.0.50727, la modification de la Configuration du bouton devient disponible (cliquable) et mes points d'arrêt a de nouveau fonctionné.

J'ai aussi réalisé qu'il pourrait être utile de vérifier l'ASP.Net version mettre dans IIS pour "Site Web par Défaut" [dans la Console IIS, développez Sites Web, clic droit sur Site Web par Défaut et sélectionnez Propriétés puis l'ASP.Net tab], de sorte que tous les nouveaux projets créés dans Visual Studio acquérir le Site Web par Défaut.

InformationsquelleAutor Lloyd Conrade
1

J'ai eu ce problème récemment (WinXP, VS2003), et j'ai essayé les solutions ci-dessus, sans succès. Ensuite, j'ai réalisé qu'il y avait plusieurs versions de la .Net runtime est installé.
Donc, j'ai apporté IIS 5.1, trouve le bon dossier virtuel, est allé dans les propriétés, puis l'ASP.NET onglet, et a changé le ASP.NET la version 4. l'? à 1,1, et il semble que cela a résolu le problème. Il se pourrait que la solution est présente, plus une ou plusieurs des opérations ci-dessus.

Aussi, tous les ci-dessus constituent un "évier de cuisine" de différentes choses à essayer. C'est comme jeter un tas de spaghettis contre le mur, en espérant que certains d'entre eux bâton.
Et, certains de ces "solutions", qui peut causer d'autres problèmes dans votre programme. Par exemple, la suggestion de réglage AutoEventWireup="true" peut causer certains de vos événements à feu deux fois!!! (voir http://support.microsoft.com/kb/814745).

InformationsquelleAutor Austin
1

Toujours regarder pour Solution Configurations être Définie Comme "Debug" pour le débogage.
Il peut changer de configuration de Version après la publication.

InformationsquelleAutor Mohamed Alikhan
0

Pour moi, les Propriétés du Projet avait été remis à zéro par un autre dev à utiliser IIS Express et pas mon IIS Local avec.
Ainsi, le projet s'est déroulé OK, mais rien a été frappé.

Clic droit sur le Projet > Propriétés > Web > Serveurs de changement de Local IIS.
Je sais que cela ne fonctionne pas pour tout le monde, mais espérons que cela aide quelqu'un.

InformationsquelleAutor Julian Rosebury
0
1. Aller à vos propriétés de la solution.
2. L'intérieur de la Configuration des Propriétés,Jeu de édifier un jeu de configuration de 'Debug' au lieu de 'libération'pour tous les projets dans votre solution.
3. Cliquez sur Appliquer, puis sur le bouton OK.
InformationsquelleAutor Pankaj Devrani
0

Dans mon cas, la question se terminant par être lié à la fois à l'aide de IIS complet (pas Express) et d'avoir une version de débogage où il inclus les symboles de débogage mais ont aussi des propriétés du projet, Build, Optimize code vérifié.

En vertu de l'Express, cela fonctionne bien, mais sous IIS cela ne fonctionne pas. Visual Studio s'attache au processus w3wp correctement, mais il ne se charge pas de symboles pour l'optimisation de la dll. Dans Visual Studio, vous pouvez aller à Debug, Windows, Modules puis faites défiler l'écran pour la dll spécifique et de voir si, en vertu de la Symbol Status colonne, il montre Skipped Loading Symbols.. Cliquez-droit dessus et sélectionnez Load Symbols pour le faire fonctionner.

Un autre paramètre qui peut affecter ce est si Visual Studio est situé à seulement déboguer le code de l'utilisateur en vertu de Debug, Options and Settings, Debugging, General, Enable Just My Code. Une fois optimisé, la dll sera marqué comme pas le code de l'utilisateur lors de l'exécution sous IIS complet, alors que Seulement Mon Code est activé, les points d'arrêt seront ignorés. Vous pouvez soit définir VS debug non le code de l'utilisateur ou de l'ensemble de la construction afin de ne pas optimiser pour les points d'arrêt permettent d'être frappé.

InformationsquelleAutor Jeremy Murray
0

Ce qui m'a poussé les noix pendant une semaine jusqu'à ce que j'ai finalement remarqué un paramètre manquant.
Cela s'appuie sur Jay Riggs réponse, mais pour Visual studio 2010 au lieu de 2005.
Dans les propriétés du projet -> Web -> Débogueurs, assurez-vous que l'ASP.NET le débogueur est cochée.

InformationsquelleAutor 5unnyr4y3
0

Debug=>Options=>Général => décocher la case "Permettre le Juste Mon Code"

Cela a fonctionné pour moi

InformationsquelleAutor BeccaGirl

Vous devez vous connecter pour publier un commentaire.