J'ai eu le fameux “Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document. ”- problème et a été inspiré par ce thread :
J'ai lancé le débogueur, ouvert Debug -> Fenêtre -> Modules, cliquez avec le bouton droit de la souris sur Assembly -> Symbol Load Information. Il pointe vers un endroit étrange:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Fichiers ASP.NET temporaires {myProjectFolder}\8df46672\bbaeb99e\Assembly\dl3\c29c5e19\aa46dcf7_10dccc01 {monProjet} .pdb: symboles chargés.
Cela a temporairement résolu le problème pour moi lorsque j'ai supprimé {myProjectFolder}
. Mais il pointe toujours vers ce fichier .pdb (VS recrée le dossier temporaire après la suppression). Je suppose que cela devrait pointer vers .pdb dans le répertoire bin si, comme dans d'autres assemblys. Comment suis-je supposé résoudre ce problème? Ou est-ce un comportement normal?
Merci pour tous les conseils ...
Edit: C’est un projet ASP.NET (.NET 4.0), MVC 3. Aucune bibliothèque COM incluse jusqu'à présent. J'ai maintenant supprimé à nouveau le répertoire mentionné ci-dessus et me suis retrouvé avec "Le point d'arrêt ne sera pas actuellement ...". Si j'ouvre la fenêtre Modules, Symbol Status affiche "Saut de chargement des simboles" pour tous les assemblys, à l'exception de App_global.asax.exot9a5x.dll.
Modifier 2: le site Web est configuré pour s'exécuter sur le local IIS 7. Si je change pour Visual Studio Development Server, le débogage fonctionne correctement. Semble être lié à IIS?
Il s'avère que j'avais défini la configuration sur Release
lorsque j'ai démarré le débogueur Lorsque je le change en Debug
, cela fonctionne comme prévu!
IIS 7, Visual Studio 2012, Publication au niveau local IIS et débogage à partir de Visual Studio.
Le problème se pose car l'application Web ne peut pas extraire le PDB à partir du dossier ASP.NET temporaire.
Avant de faire quoi que ce soit, Redémarrez le app_pool pour votre application Web dansIIS
Une autre solution au problème des points d'arrêt avec un fichier javascript consiste à vider le cache IE9. J'ai rencontré ce problème après la mise à jour/l'enregistrement d'un fichier js. Le débogueur de Visual Studio 2012 ne mettra pas à jour le .pdb jusqu'à ce que je sois entré dans les options Internet et que j'ai supprimé les fichiers Internet temporaires. J'espère que cela sauvera du temps à quelqu'un.
Juste une note sur mon problème avec ça, ça semble un peu ridicule à la fin, mais j'ai quand même perdu une heure de panique.
J'ai dû désinstaller Nuget pour pouvoir le mettre à jour. Après avoir installé le nouveau nuget et le paquet que j’étais après avoir reçu l’erreur de point d’arrêt.
Il s'avère que lors de ces installations, mes paramètres de publication ont perdu le port spécifique sur lequel j'exécutais le projet dev. Étant donné que j’étais tellement habitué à ce numéro de port pendant les 4 derniers mois, je n’y pensais même pas, mais je pensais tout le temps que je regardais la machine de développement, elle ne fonctionnait pas réellement regardait les pages en cache qui étaient déjà dans mon navigateur. DER!
Cela semble probablement stupide, mais si cela aide quelqu'un.
Codage heureux, K
J'ai répondu à une question similaire qui pourrait résoudre votre problème. Il était courant de laisser coché "exclure les symboles de débogage générés" dans les paramètres de publication. Regardez ma réponse: https://stackoverflow.com/a/16202843/2208689
Pour résoudre ce problème dans VS 2015, je devais:
Le problème est apparu lorsque je me suis trompé avec le gestionnaire de configuration de build et que j'ai ajouté le mien. D'une certaine manière, cela a changé le paramètre Informations de débogage dans le projet.
Assurez-vous d’installer non seulement VS2010, mais également VS2010 Service Pack 1 .
J'ai essayé toutes les solutions affichées, y compris la réinstallation - même sur un nouvel ordinateur, sans succès! Vous avez besoin du service pack. Après l'avoir obtenu, essayez les autres solutions affichées si le problème persiste.
Pour résoudre ce problème dans Web.config, il me suffisait d'ajouter debug="true"
<system.web>
<compilation targetFramework="4.0" debug="true">
Ce qui m'a aidé à trouver cette solution, c'est de regarder les fenêtres Modules} lors du débogage et de constater que pour mes DLL ASP.NET chargées, j'avais: Binary n'était pas construit avec les informations de débogage.