Impossible de démarrer le débogage sur le serveur web. Impossible de démarrer le débogage ASP.NET VS 2010, II7, Win 7 x64
J'exécute Visual Studio 2010 (en tant qu'administrateur), IIS 7 sous Windows 7 x64 . Je peux exécuter le site Web ASP.NET dans IIS 7 sans déboguer parfaitement, mais quand J'appuie sur F5 pour le déboguer, je reçois:
Impossible de démarrer le débogage sur le serveur web. Impossible de démarrer le débogage ASP.NET. Plus d'informations peuvent être disponibles en démarrant le projet sans débogage.
Malheureusement, le lien d’aide ne m’aide pas beaucoup et mène à un sacré arbre.
J'ai vérifié les points suivants:
Exigences de sécurité - Je ne me souviens pas d'avoir à faire quelque chose de spécial auparavant. Le processus de travail dans IIS7 est w3wp.exe. Il indique que s'il fonctionne en tant que ASPNET ou NETWORK SERVICE, je dois disposer des privilèges d'administrateur pour le déboguer. Comment savoir si je dois changer quelque chose ici?
Pages de propriétés de site Web> Options de démarrage> Débogueurs> ASP.NET est coché . Utiliser serveur personnalisé est défini sur l'URL du site (ce qui fonctionne correctement sans débogage).
Le débogage est activé dans
web.config.L'application utilise ASP.NET 3.5 (je souhaite éventuellement passer à la version 4.0, mais j'ai une certaine migration à gérer).
Pool d'applications: Classer .NET AppPool (également essayé DefaultAppPool).
Des idées où je peux vérifier ensuite?
Il ne devrait certainement pas être aussi difficile d’installer IIS, VS, de créer un site Web et de commencer à le tester?
Merci d'avance.
Il s'avère que le coupable était le module IIS Url Rewrite. J'avais défini une règle redirigeant les appels vers Default.aspx (qui était définie en tant que page de démarrage du site Web) vers la racine du site afin de pouvoir disposer d'une URL de départ canonique. Cependant, apparemment, VS avait un problème avec cela et était confus. Ce problème ne s'est pas produit lorsque j'utilisais Helicon ISAPI_Rewrite, donc il ne m'est même pas venu à mon sens de vérifier.
J'ai fini par créer un tout nouveau site Web en partant de zéro et en transférant petit à petit des projets/fichiers dans ma solution, puis en reconstruisant mon fichier web.config jusqu'à ce que je le découvre!. .NET 4.0 (jusqu'à présent, j'espère que je ne tomberai pas dans les murs) - mais quelle douleur!
Essayez d’aller dans IIS et de vérifier que le pool d’applications que vous utilisez est démarré. Souvent, vous allez générer une erreur qui ferme le pool d'applications. Vous avez juste besoin de faire un clic droit et Démarrer et vous devriez être bon pour aller.
Lors du démarrage, Visual Studio tentera (pour une raison quelconque) d’accéder à l’URL:
/debugattach.aspx
Si vous avez une règle de réécriture qui redirige (ou intercepte autrement), disons, .aspx fichiers, ailleurs, vous obtiendrez cette erreur. La solution consiste à ajouter cette section au début de la section web.config de votre <system.webServer>/<rewrite>/<rules>:
<rule name="Ignore Default.aspx" enabled="true" stopProcessing="true">
<match url="^debugattach\.aspx" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="None" />
</rule>
Cela vous permettra de capturer cette requête en particulier, de faire rien et, plus important encore, d'arrêter l'exécution afin qu'aucune de vos autres règles ne soit exécutée. Ceci est une solution robuste, alors n'hésitez pas à le garder dans votre fichier de configuration pour la production.
Pour le bénéfice des autres, dans mon cas, j'avais configuré le pool d'applications pour utiliser mes informations d'identification Windows afin d'accéder à un partage de ressources réseau. Depuis le dernier débogage de la solution, j'avais réinitialisé mon mot de passe Windows. Mot de passe modifié stocké dans le pool d'applications et bada bing.
Si ApplicationPool Identity est défini sur un compte personnalisé et que le mot de passe de l'ordinateur est modifié, vous devez mettre à jour votre mot de passe.
Pour mon scénario, il s'agissait de modifications de la section httpErrors dans web.config, en le configurant comme suit:
<httpErrors mode="Custom">
a provoqué le problème "Impossible de démarrer le débogage sur le serveur Web". La remise à la valeur précédente de "DetailedLocalOnly" a résolu le problème. En creusant un peu plus profondément, j'ai découvert que c'était en fait juste le paramètre d'erreur 401 qui causait ceci:
<httpErrors mode="Custom">
<error statusCode="401" prefixLanguageFilePath="" path="/masterpages/500.html" responseMode="ExecuteURL" />
<httpErrors mode="Custom">
Commenter la ligne d'erreur 401 a également résolu le problème. Je suis allé à cette idée car je peux ensuite gérer la gestion des erreurs personnalisée et commencer par le débogage.
Je ne sais toujours pas pourquoi cela se produit.
Veuillez vérifier le pool d'applications. si c'est arrêté. redémarrez-le.
Avait le même problème essayant de déboguer un module DNN (Dot Net Nuke) . Il s'avère que vous devez avoir la compilation debug = "true":
<compilation debug="true" strict="false" targetFramework="4.0">
dans votre web.config. Par défaut, il est faux dans DNN. Source originale ici: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts
J'ai exactement le même problème après avoir implémenté le module de réécriture.
Si je supprime les entrées de réécriture de mon fichier web.config, le débogage fonctionne parfaitement.
Pour résoudre ce problème, je viens de commenter les balises de réécriture lors du débogage, comme ceci ...
<rewrite>
<rules>
<rule name="LowerCaseRule_1" stopProcessing="true">
<match url="[A-Z]" ignoreCase="false" />
<action type="Redirect" url="{ToLower:{URL}}" />
</rule>
<rule name="RedirectDefault.aspx_1" stopProcessing="true">
<match url="(.*)default.aspx" />
<action type="Redirect" url="{R:1}" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
Je supprime ensuite les commentaires après le débogage.
Doit être un bug dans Visual Studio 2010.
J'ai eu la même erreur depuis que le pool d'applications a été arrêté dans IIS. Après le démarrage du pool d'applications, le problème a été résolu.
Voici ce que j'ai fait pour effacer l'erreur que vous avez notée. Recherchez le dossier Web de l'application dans le système de fichiers, accédez à Propriétés => Sécurité cliquez sur le bouton Avancé puis cliquez sur l'onglet Propriétaire , cliquez sur le bouton Éditer et modifiez le propriétaire (avec les autorisations appropriées) du dossier et a coché la case " Repalce owner sur les sous-conteneurs et les objets ". Cliquez sur " Apply " puis j'étais en affaires (capable de déboguer).
J'espère que cela fonctionne pour quelqu'un d'autre.
Vient enfin de résoudre ce problème pour ma seule solution. Deux des projets de la solution ont été définis en tant que sites dans IIS. Je suis entré et j'ai activé l'emprunt d'identité ASP.Net sous Authentification pour les deux projets ... et VIOLA! FINALEMENT, plus de cette erreur ennuyeuse!
Si le pool d'applications a des difficultés à redémarrer ou ne veut tout simplement pas le redémarrer, vérifiez si Windows a mis à jour récemment la version 4.0 sur ASP.NET v4.0 ou un autre pool d'applications. C'est ce qui s'est passé dans mon cas. J'ai simplement redémarré mon ordinateur, puis redémarré ASP.NET v4.0 App Pool et tout fonctionnait encore!
Je recevais le même message d'erreur dans VS 2012, mais je n'exécutais pas en tant qu'administrateur. Lorsque j'ai lancé l'application en tant qu'administrateur, j'ai reçu un message différent et légèrement plus utile (que j'ai pu comprendre). HTH
Dan,
En plus des suggestions d'Aaron, essayez ce qui suit
- Vérifiez que l'authentification Windows intégrée est sélectionnée sur votre site Web IIS.
- Pouvez-vous déboguer en utilisant Cassini au lieu d'IIS?
Avait le même problème avec Windows 10 lorsqu'il a activé toutes les fonctionnalités de Windows IIS. Basculé sur Windows 8.1 et a encore un problème. La racine était dans le nom du site Web " http: //MySite.local " (non lié à la version du système d'exploitation).
Et la solution est simple
Editer le fichier hôtes dans
%SystemRoot%\System32\drivers\etc\Ajouter une ligne avec liaison IP:
127.0.0.1 MySite.local
Vérifiez si votre site Web sur IIS n'est pas arrêté.
Je l'ai corrigé pour mettre mon site web en marche. :RÉ
Assurez-vous que le pool d'applications de votre site utilise la version correcte de la structure . J'ai l'erreur "Impossible de démarrer le débogage" sur un site ASP.Net 2005. Il utilisait incorrectement DefaultAppPool sur Windows 7 (qui, je crois, utilisait .Net Framework 4). J'ai créé un nouveau pool d'applications basé sur .Net Framework 2 et l'ai affecté au site Web posant problème. Après ce débogage a bien fonctionné.
avait le même problème. Si un certificat SSL est installé sur IIS et que vous essayez de le déboguer à partir de Visual Studio, vous devez définir votre application sur IIS pour ignorer le certificat.
J'ai eu ce problème et finalement réalisé que je suis ASP.net n'est pas enregistré correctement avec IIS. Cela peut se produire lorsque le serveur IIS est installé avant Visual Studio. Pour résoudre ce problème, utilisez la commande aspnet_regiis -i Des informations complémentaires sont disponibles dans/ link
J'ai eu le même problème dans Visual Studio 2012 et 2013 sur Windows 8.1. Pour moi, le correctif consistait à ajouter l'authentification Windows à IIS en utilisant "Activer ou désactiver des fonctionnalités Windows".
J'ai eu le même problème et j'ai trouvé que c'était dû à un caractère tapé par erreur dans mon Web.config après la balise de fin. Mon Web.config ressemblait à ceci à la fin: </section>h. Le "h" était un caractère supplémentaire après la balise de fermeture.
J'ai eu cette erreur aujourd'hui en raison d'un défaut dans le code qui a été publié en arrière beaucoup de fois provoquant IIS être inondé de demandes. Cela a essentiellement bloqué IIS et donc, lorsque j'ai essayé de déboguer, le délai a expiré et le démarrage du débogueur a expiré. J'ai simplement redémarré IIS, ce qui a pris quelques minutes et le problème a été résolu.
Je voudrais bien que cette erreur soit moins générique, il semble y avoir plusieurs façons de la produire.
J'ai eu le même problème lorsque j'ai créé l'application dans Visual Studio, puis dans les propriétés, créé le répertoire virtuel à utiliser avec IIS local. Si quelqu'un a cette erreur, c’est que VS crée une application avec un mauvais AppPool, c’est-à-dire avec un AppPool, ce qui ne répond pas à vos besoins.
Si tel est le cas, accédez au gestionnaire IIS, sélectionnez App, accédez aux paramètres de base, modifiez AppPool for App et vous êtes prêt à partir.
La désinstallation de IIS UrlScan Extension a résolu le problème pour moi.
J'ai trouvé ce problème aussi, mais il ressemblait beaucoup à ce que @Kirk a expliqué et à la réécriture d'URL.
Dans mon cas, quelqu'un avait archivé cette modification dans le fichier web.config pour un projet MVC:
<system.webServer>
<security>
<requestFiltering>
<fileExtensions>
<add fileExtension=".aspx" allowed="false" />
</fileExtensions>
</requestFiltering>
</security>
</system.webServer>
Les extensions de fichier .aspx n'étant pas autorisées sur le serveur Web, l'URL /debugattach.aspx a été refusée, ce qui a empêché le débogueur de s'exécuter. Une fois que j'ai supprimé cette configuration, cela a fonctionné à nouveau.
J'ai eu cette même erreur récemment et dans mon cas, il s'est avéré qu'il y avait des types MIME en double. J'avais récemment ajouté deux personnes qui ne figuraient pas initialement dans la liste. IIS m'a laissé les ajouter et ce n'est que lorsque j'ai décidé de vérifier les types MIME du site dans le cadre de mon processus de diagnostic que j'ai également reçu une erreur dans IIS. Il a référencé les doublons dans web.config. Une fois revenu dans le fichier web.config, j'ai remarqué qu'une nouvelle section appelée avait été ajoutée, qui comprenait les deux types MIME récemment ajoutés. Supprimé cette section et la vie est belle à nouveau! En espérant que cela puisse aider d'autres personnes qui n'ont pas réussi à résoudre le problème avec l'une des autres suggestions.
J'avais rencontré le même problème, mais c’était sur le serveur de développement Web de Visual studios au lieu d’IIS.La solution consiste à décocher l’option dans l’onglet Web sous les propriétés du projet, Appliquer les paramètres du serveur à tous les utilisateurs (stocker dans un fichier de projet.). cela fera gagner un temps précieux à quelqu'un.
J'ai eu le même problème… .. Toutes les réponses ci-dessus n'ont pas fonctionné pour moi… .. La solution a été de supprimer manuellement le dossier bin et obj.
supprimez sting comme ceci: targetFramework = "4.0" dans web.config ou remplacez AppPool par la version de structure appropriée.