10
votes

Qu'est-ce que débugatach.aspx et pourquoi le serveur ne peut-il pas le trouver?

Je développe une machine XP (SP3) avec VS 2010 et IIS 5.

J'ai deux versions du même site. Nous avons publié notre première version de production. J'ai donc ramené le code dans un nouvel arborescence de répertoire et créer de nouveaux répertoires virtuels dans IIS pour pointer vers les nouveaux arbres. Les projets sont configurés pour exécuter dans le serveur IIS plutôt que contre VS. Le site principal est un projet basé sur MVC 2.

Mon problème est que, lorsque je frappe F5 dans Visual Studio 2010 pour commencer à déboguer la nouvelle version, je reçois un "Impossible de démarrer le débogage sur le serveur Web. Le serveur Web n'a pas pu trouver la ressource demandée". J'ai passé la meilleure partie d'hier pour essayer de comprendre quelle ressource il cherchait que cela ne pouvait pas trouver. Cela se produit avant que cela ne reçoive jamais "Démarrage de l'application". J'ai enfin pensé à regarder dans les journaux Web et j'ai constaté que chaque fois que je frappe la clé F5, le journal Web affiche une demande de débogage pour /Debugattach.aspx, avec un code de retour de 404 (non trouvé). Si j'exécute la même séquence sur l'ancienne version, elle montre la même chose, mais d'abord avec un code 401, puis la demande répétée avec un code 200.

Ma première pensée était que VS devait écrire un fichier "debugattach.aspx", puis l'appelant, et peut-être qu'il n'a pas l'autorisation d'écriture dans le répertoire, mais, autant que je puisse dire, il fait .

J'ai googled Debugattach.aspx, et les premières pages d'articles qui sont renvoyées semblent faire référence à des horizons et aux délais d'attente, principalement sur IIS 7 et VS 2005. Rien qui semble appliquer à cette situation.

En regardant ce qui est différent entre l'ancienne version qui fonctionne et la nouvelle version qui ne le fait pas, les seules choses sont la configuration IIS des répertoires virtuels et le web.config sur le code lui-même. Mais je suis allé sur les deux sites côte à côte et je ne trouve aucune différence qui explique ce comportement.

Quelqu'un a-t-il un indice qu'ils peuvent partager avec moi? Ou quelqu'un peut-il me signaler à toute documentation sur ce que fait exactement débugatach.aspx est / fait / quelle demande HTTP de débogage fait et / ou comment vs les utilise?

Merci d'avance.


2 commentaires

S'il vous plaît ignorer. J'ai trouvé la solution. Je ne comprends pas, mais je l'ai eu pour travailler. Je suis retourné une fois de retour et comparé les propriétés IIS des deux sites côte à côte et découvrit une différence. Dans le mappage d'extension d'application, où j'avais ajouté aspnet_isapi.dll en tant que mappage de carte sauvage afin que l'URL sans extension soit exécutée via le mappage MVC, la case à cocher "Scripting Scripting" a été cochée sur le site qui ne fonctionnait pas et non vérifié sur le site qui était. J'ai retiré cela et j'ai essayé à nouveau et le débogage a commencé.


Bien que ce soit un ancien poste, vous pouvez toujours obtenir un crédit pour publier votre propre réponse =)


9 Réponses :


-2
votes

Ajouter à votre web.config.


1 commentaires

Slaks, j'apprécie la réponse, mais le débogage a été défini sur True depuis le jour de l'un de ce projet.



0
votes

Je viens de courir dans cela aussi. J'avais désactivé les extensions de noms de fichiers autorisez-les Sous Filtrage de la requête sur mon serveur IIS local (pour correspondre à nos paramètres de sécurité durcis dans d'autres environnements). S'avère .aspx était bloqué. J'ai remis le réglage et je pouvais attacher avec le débogueur. Donc, je l'ai renversé et ajouté une indemnité au niveau du site pour .aspx et je peux joindre avec le débogueur une fois de nouveau.

Je suis curieux de savoir pourquoi le débogueur recherche debugattach.aspx et à défaut avec cette erreur. Surtout que mon application est MVC et je n'ai pas besoin de servir .aspx.


0 commentaires

0
votes

J'ai eu une carte de script wildcard pour la version .NET 4 de aspnet_isapi.dll qui l'a causait cela. J'ai pu changer le mappage de script pour ignorer le verbe de débogage (en utilisant uniquement les verbes dont j'avais besoin pour mon application) et qui a été activé VS de s'attacher automatiquement.

Cela dit, j'ai fini par utiliser le serveur Web de développement VS ou IIS Express pour obtenir mon site fonctionner sur une machine XP, car IIS 5.1 n'aimait pas le combo de la carte de script Wildcard et de l'acheminement ASP.NET.


0 commentaires

5
votes

basé sur Old Posting , Debugattach.aspx est implémenté par le système HTTP Handler System.web.httpdebugghandler. Je n'ai pas vu ce gestionnaire référencé nulle part dans IIS7, il est possible que cette mise en œuvre ait été fusionnée dans un autre gestionnaire sur la route. Définitivement une sorte de gestionnaire cependant. Quand cela fonctionne, vous voyez 200 (succès) des messages dans les journaux.

J'ai eu ce même problème 2 différentes manières, où le débogage F5 a échoué dans VS2010 en raison d'un problème d'atteinte au gestionnaire de débogage. L'utilisation des journaux de traçage de la demande IIS a échoué, j'ai pu voir des instances dans lesquelles des modules IIS interfèrent. En une fois cas, URLScan.dll bloquait le verbe de débogage. Dans une autre, une redirection de HTTP à HTTPS a entraîné le retour du gestionnaire de débogage de revenir 302. Dans les deux cas, vs barbare d'une boîte de dialogue similaire.

En tout cas, le truc ici semble déterminer comment une demande de débogage à cette URL peut être bloquée.


1 commentaires

Visual Studio va enregistrer des erreurs relatives à Debugattach.aspx ici:% userprofile% \ appdata \ local \ Tempdata \ Visual Studio Web débogger.log (si vous n'avez pas ce fichier - ou si c'est un ancien fichier - alors votre problème n'est probablement pas lié à Debugattach.aspx.)



0
votes

Si vous exécutez VS2010 ou plus tard et que vous avez installé .NET 4.x ou plus tard, essayez de renommer le sous-répertoire "V3.0" (par exemple "Rename C: \ Windows \ Microsoft.net \ Framework \ v3.0 v3.0.Oréiginal "), redémarrez votre machine et essayez de déboguer à nouveau dans Visual Studio.

Cela a travaillé comme un charme sanglant pour moi, mais votre kilométrage peut varier, en fonction du type de développement que vous faites.

J'ai exécuté Visual Studio 2012 pendant deux semaines comme celle-ci, et je ne peux sérieusement pas croire à quel point les choses sont rapides (à nouveau!). Le lancement du débogueur avec F5 est instantané maintenant et l'arrêt de la session de débogage est également instantané. Toutes sortes de comportements buggy et laggy ont cessé, et jusqu'à présent, je n'ai pas vu d'effet secondaire unique.


0 commentaires

0
votes

La solution qui fonctionne pour moi était de redémarrer Vstudio en mode administrateur.


0 commentaires

4
votes

Dans mon cas, j'avais créé une application Web vide avec VS2017 sous Windows 10. Lorsque je décoché la case du débogueur ASP.NET sous Paramètres du projet -> Web Le problème est parti. Avant cela, j'ai essayé presque toutes les suggestions pour résoudre le problème.


1 commentaires

+1 ty sir. Correction de mon problème qui mâchait des heures. Mon erreur officielle a été une erreur: impossible de démarrer le débogage sur le serveur Web. Le serveur distant a renvoyé une erreur: (403) interdit



1
votes

Pour des raisons de performance, nous avons supprimé tous les gestionnaires du de notre web.config sauf pour staticfile et extensionSurlHandler-intégré-4.0 , puis a commencé à obtenir cette erreur lors du débogage de Visual Studio.

Après une enquête, nous avons découvert qu'à une utilisation normale, quel que soit le module qui gère cette demande permet simplement de trouver http. Erreur 401 (non autorisé) à retourner. Je n'ai pas pu trouver exactement quel module c'était, mais j'ai pu trouver la classe qui est responsable: system.web.httpdebugghandler .

Par conséquent, nous avons ajouté ce qui suit ligne dans notre web.config gestionnaires: xxx

Lorsque cette URL est touchée, IIS donne un 401 comme lorsque tous les gestionnaires sont activés. Visual Studio est à nouveau heureux.

Voir aussi: https://developercommunity.visualstudio.com/content/problem/464980/Unable-a-start-debugging-when-vs- ge.html


0 commentaires

0
votes

J'ai couru dans ce numéro de fichier debugattach.aspx récemment. Pour moi, cela a commencé avec un message d'erreur essayant de déboguer une demande ASP.NET via VS 2017. Après avoir passé deux jours après toutes les suggestions sur le net, j'ai finalement trébuché sur cette chose debugattach.aspx. Je voulais aussi savoir ce que c'était et pourquoi IIS renvoyait une réponse de 403 ans aux demandes de celui-ci.

Longue histoire courte, cela m'est arrivé parce que l'application que je voulais déboguer était arrivée dans un répertoire virtuel sous une autre application Web. Je devais m'assurer que le drapeau a été défini sur l'application "Parent", même si je n'étais pas intéressé à déboguer celui-là.

Un slappeur de tête à la fin. Espérons que cela aide quelqu'un d'autre à qui essayer de suivre les problèmes liés à Debugattach.aspx.


0 commentaires