Pourquoi suis-je incapable de déboguer sur mon site Web ASP.NET dans Visual Studio?
J'avais l'habitude de pouvoir attacher à mon processus w3wp et à déboguer mon application Web, mais cela ne fonctionne plus. Je ne sais pas ce qui a changé pour casser ça. J'utilise Visual Studio 2008 SP1. Et je débogue dans IIS sans utiliser le serveur d’ASP.NET (c’est-à-dire que je n’exécute pas mon projet, je l’attache simplement à un processus en cours (w3wp).
Mes points d'arrêt ont simplement le "point d'arrêt ne sera pas touché actuellement. Le code source est différent de la version d'origine."
Ce que j'ai essayé
- A fait une solution Clean.
- A fait une solution Rebuild.
- Assurez-vous que la compilation debug = true dans mon fichier web.config.
- Supprimé le dossier bin
- Visual Studio redémarré
- IIS redémarré
- Redémarré mon ordinateur
- Ajout d'un Response.Write simple pour s'assurer que le dernier DLL est utilisé. Il est.
- Assurez-vous que Debug ASP.NET est coché dans les propriétés de mon projet. Il est.
- Assurez-vous que tous mes projets sont compilés dans ma configuration de construction. Elles sont.
Mais aucune de ces aides. J'attache à w3wp, mais mes points d'arrêt ne sont jamais touchés.
Des idées?
J'ai eu ce problème récemment et je me suis d'abord assuré que Visual Studio ne fonctionnait pas du tout sur le système.
Puis allé dans ce dossier et supprimé tout son contenu:
C:\windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\
Vérifiez votre web.config pour
<compilation debug="true">...
Lorsque vous "Attachez au processus", la fenêtre de sortie devrait vous montrer (quand vous affichez le résultat de "Debug") toutes les bibliothèques qu'il charge, et d'où il les charge - pour les dll dans votre dossier/bin, elles sont généralement copiées dans le répertoire. \Temporary ASP.NET Files\root\ folder - où sont les vôtres lus? Les avez-vous définitivement effacés de là?
Les seules autres choses auxquelles je peux penser:
- Vous avez compilé votre code en mode "Publication" au lieu de "Débogage" (pas le fichier web.config) dans la liste déroulante Configuration de la solution.
- Les fichiers de symboles (.pdb) sont absents de votre dossier/bin.
Sous l'onglet "Construire" des propriétés du projet, vous êtes dans la configuration "Actif (Debug)", vous n'avez pas coché "optimiser le code"?
Si vous cliquez sur "Avancé ..." dans cet onglet, quelle valeur avez-vous pour "Informations de débogage"? Est-ce "complet" ou "aucun"?
Répondre au commentaire
Il sera plus difficile de déboguer avec succès si votre code est compilé en mode "Publication" et vous obtiendrez souvent le message "Le code source est différent" si vous n'avez pas reconstruit les symboles (fichiers .pdb) après les modifications - mais vous disons que vous avez nettoyé/reconstruit, de sorte que devrait couvre cela.
Oui, votre fenêtre de sortie montrera toutes les dll du framework que vous référencez ainsi que votre code - mais vous devriez voir un fichier répertorié avec le nom de chaque sortie du projet - ce sont ceux-là à regarder.
Vous n'avez pas d'événement post-build qui déplace les fichiers dans le bon répertoire pour votre site, est-ce que vous échouez silencieusement?
J'ai également eu ce problème, résolu en modifiant le type de code "Attacher à" sur Automatique dans la boîte de dialogue "Attacher au processus". (Auparavant, cette option était configurée sur "Code Silverlight" en raison du débogage d'un processus différent ... il peut être facile d'oublier de modifier ce comportement.)
Je sais que cette question est ouverte depuis un certain temps, mais je pense que c'est la même chose que j'ai connue:
Je ne pouvais pas déboguer mon code côté serveur .aspx. J'avais un projet WepApp AnyCPU qui fonctionnait et je voulais créer un lien vers des dll x86. J'ai donc créé une cible de débogage x86. A fait des choses similaires, reconstruit, arrêté le serveur Web de développement, redémarré, effacer les fichiers temporaires, en vain.
Correction du problème en modifiant le dossier cible en bin\(bin\x86\Debug).
Exécutez-vous des add-in qui pourraient affecter ceci? Ou tous les outils qui appliquent des opérations de post-génération au code source par lequel les DLL avec lesquelles vous commencez le débogage ont été modifiés et il est en fait correct de dire que ce n'est pas le même code source et que le débogage ne fonctionnera donc pas?
Aussi ont essayé de réinitialiser VS?
devenv.exe /resetsettings
Edit: si aucune des informations ne vous a aidé, bien que pénible, il pourrait être utile de désinstaller et de réinstaller VS et SP1. Si vous passez par là et que le problème est le même par la suite, cela garantit au moins que le problème réside dans les paramètres web.config ou du projet.
Avez-vous vérifié votre fichier Assembly.cs avec cet attribut
[Assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.Default)]
Après avoir réfléchi à un code optimisé, vous obtiendrez probablement ceci. Donc, vous devez supprimer ceci pour pouvoir déboguer à nouveau.
J'ai fait face au même problème. Le processus w3wp a pris beaucoup de mémoire et ne voulait pas être réinitialisé lors de la publication d'applications Web.
Appuyez sur Ctrl + Alt + Suppr> Allez à l'onglet "Processus"> trouvez le processus w3wp et éliminez-le. Réexécutez l'application (s'il s'agit d'une application MVC, accédez simplement à une URL associée pour recréer automatiquement le processus W3WP).
Les avertissements disparaîtront après cela.
dans la boîte de dialogue "Attacher au processus", cochez la case "Afficher les processus de tous les utilisateurs" (près du bas). Si deux processus w3wp.exe apparaissent, essayez l'autre.
On devrait avoir une valeur de commentaires/description de quelque chose comme T-SQL, géré quelque chose d’autre. C'est celui que tu veux.
J'ai essayé toutes les options ci-dessous dans Visual Studio 2013 Update 4.
- Réinitialiser IIS
- Solution propre et reconstruction
- Supprimer les fichiers du dossier temporaire C:\Windows\Microsoft.Net\Framework ...\Fichiers ASP.NET temporaires
- Vérifier si la balise de compilation est debug ou pas
Mais aucun d’entre eux n’a fonctionné, je vous énumère ici les deux choses qui ont fonctionné pour moi.
- Désactiver l'option "Just My Code" Outils -> Options -> Débogage -> Général -> Désélectionnez Activer Just My Code.
- Editez le fichier web.config et sauvegardez-le (vous pouvez toujours créer un espace dans n’importe quelle ligne de web.config, cela suffira)
Veuillez noter que cette solution peut être spécifique à la version de Visual Studio et que le correctif a fonctionné pour moi dans Visual Studio 2013 Update 4.
Dans mon cas, j'avais une application console la page Web hébergée dans .Net Framework 4.6.1. Quand j'ai ajouté un Debug à Symboles de compilation conditionnels , cela a commencé à fonctionner:
Sur OpenVMS, nous avions l'habitude de:
Compiler/Debug puis Link/Debug
et c'était ça! Simples !!
mais sérieusement, assurez-vous que le fichier dans lequel se trouve votre ligne Debugger.Break a la propriété 'Copier toujours' dans ses propriétés avant de reconstruire
J'utilisais les commandes VSCommandes d'extension Visual Studio pour attacher le débogueur (pratique). Cependant, IIS Express était en cours d’exécution et j’imaginais qu’il pouvait interférer. En effet, lorsque je j'ai fermé IIS Express , tout à coup, j'ai pu déboguer à nouveau.
La joie s'ensuivit.
J'ai ce problème depuis un moment et j'ai trouvé ma solution sur le forum MS (lien ci-dessous). L'outil de diagnostic de débogage était le coupable pour moi, mais je n'avais pas à le désinstaller. J'avais une règle de crash configurée pour le processus w3wp et j'ai simplement supprimé cette règle et tout redémarré.