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'utilise Visual Studio 2010 (en tant qu'administrateur), IIS 7 sur Windows 7 x64. Je suis capable d'exécuter le site Web ASP.NET dans IIS 7 sans débogage, mais lorsque j'appuie sur F5 pour le déboguer, j'obtiens:

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é grand arbre de choses.

J'ai vérifié les éléments suivants:

• Exigences de sécurité - Je ne me souviens pas avoir à faire quelque chose de spécial auparavant. Le processus de travail dans IIS7 est w3wp.exe. Il dit que s'il fonctionne en tant qu'ASPNET ou SERVICE RÉSEAU, je dois avoir des privilèges d'administrateur pour le déboguer. Comment savoir si je dois changer quelque chose ici?

• Pages de propriétés du site Web> Options de démarrage> Débogueurs> ASP.NET est coché. Utiliser le serveur personnalisé est défini sur l'URL du site (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 migration à gérer).

• Pool d'applications: Classing .NET AppPool (également essayé DefaultAppPool).

Des idées où je peux vérifier ensuite?

Il ne devrait certainement pas être si difficile d'installer IIS, VS, de créer un site Web et de commencer à le tester?

Merci d'avance.

Essayez d'accéder à IIS et vérifiez que le pool d'applications que vous utilisez est démarré. Souvent, vous produirez une erreur qui fermera le pool d'applications. Il vous suffit de faire un clic droit et de démarrer et vous devriez être prêt à partir.

Il s'avère que le coupable était le module IIS Url Rewrite . J'avais défini une règle qui redirigeait les appels vers Default.aspx (qui était défini comme la page de démarrage du site Web ) vers la racine du site afin que je puisse avoir une URL d'accueil 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 à l'esprit de vérifier.

J'ai fini par créer un tout nouveau site Web à partir de zéro et porter petit à petit des projets / fichiers dans ma solution et reconstruire mon web.config jusqu'à ce que je le découvre! Eh bien, au moins maintenant, j'ai un site légèrement plus propre utilisant .NET 4.0 (jusqu'à présent, j'espère que je ne tomberai pas dans les murs) - mais quelle douleur!

Visual Studio, lors du démarrage, tentera (pour une raison quelconque) d'accéder à l'URL:

/debugattach.aspx

Si vous avez une règle de réécriture qui redirige (ou capture), disons, des .aspxfichiers, ailleurs, vous obtiendrez cette erreur. La solution est d'ajouter cette section au début de votre web.configde » <system.webServer>/<rewrite>/<rules>section:

<rule name="Ignore Default.aspx" enabled="true" stopProcessing="true">
    <match url="^debugattach\.aspx" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
    <action type="None" />
</rule>

Cela garantira de capturer cette demande particulière, de ne rien faire et, surtout, d'arrêter l'exécution afin qu'aucune de vos autres règles ne soit exécutée. C'est une solution robuste, alors n'hésitez pas à la conserver 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 la définissant comme ceci:

<httpErrors mode="Custom"> 

a provoqué le problème «Impossible de démarrer le débogage sur le serveur Web». Le remettre à la valeur précédente de "DétailléLocalOnly" 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"> 

En commentant la ligne d'erreur 401, j'ai également résolu le problème, car je peux ensuite maintenir la gestion des erreurs personnalisée et commencer le débogage.

Je n'ai toujours aucune idée de pourquoi cela se produit.

Vérifiez le pool d'applications. s'il est arrêté. redémarrez-le.

J'ai eu le même problème en essayant de déboguer un module DNN (Dot Net Nuke). Il s'est avéré 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 contourner cela, 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 bogue 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. Localisez le dossier Web de l'application dans le système de fichiers, allez dans Propriétés => Sécurité cliquez sur le bouton Avancé puis cliquez sur l' onglet Propriétaire , cliquez sur le bouton Modifier et changez le propriétaire (avec les autorisations appropriées) du dossier et cochez la case " Repalce propriétaire sur les sous-conteneurs et les objets ». Cliquez sur « Appliquer » et j'étais en affaires (capable de déboguer).

J'espère que cela fonctionne pour quelqu'un d'autre.

Je viens de résoudre ce problème pour ma solution unique qui avait cela. 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!

J'obtenais le même message d'erreur dans VS 2012, mais je ne fonctionnais pas en tant qu'administrateur. Lorsque j'ai exécuté 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

Si le pool d'applications a du mal à redémarrer ou ne veut tout simplement pas redémarrer, vérifiez si Windows a effectué une mise à jour récente 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é le pool d'applications ASP.NET v4.0 et tout fonctionnait à nouveau!

Dan,

En plus des suggestions d'Aaron, essayez ce qui suit

• Vérifiez que l'authentification Windows intégrée est sélectionnée dans votre site Web IIS
• Pouvez-vous déboguer en utilisant Cassini au lieu d'IIS?

Eu le même problème avec Windows 10 lorsqu'il est activé toutes les fonctionnalités de Windows IIS. Je suis passé à Windows 8.1 et j'ai de nouveau un problème. La racine était dans le nom du site Web " http: //MySite.local " (sans rapport avec la version du système d'exploitation).

Et la solution est simple

• Modifier le fichier d'hôtes dans %SystemRoot%\System32\drivers\etc\

• Ajouter une ligne avec une liaison IP: 127.0.0.1 MySite.local

J'ai eu cette erreur survenue aujourd'hui en raison d'un défaut de code qui a été renvoyé un très grand nombre de fois, provoquant l'inondation d'IIS avec des demandes. Cela a essentiellement verrouillé IIS et donc, lorsque j'ai essayé de déboguer, il a expiré en essayant de démarrer le débogueur. J'ai simplement redémarré IIS, ce qui a pris quelques minutes, et cela a résolu le problème.

Je souhaite bien que cette erreur soit moins générique, il semble qu'il existe plusieurs façons de la produire.

J'ai eu le même problème dans Visual Studio 2012 et 2013 sous Windows 8.1. Pour moi, le correctif consistait à ajouter l'authentification Windows à IIS en utilisant `` Activer ou désactiver les fonctionnalités Windows ''

Assurez-vous que le pool d'applications de votre site utilise la bonne version du framework . J'ai eu l'erreur «Impossible de démarrer le débogage» sur un site ASP.Net 2005. Il n'utilisait pas correctement 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 du problème. Après cela, le débogage a bien fonctionné.

Vérifiez si votre site Web sur IIS ne s'arrête pas.

Je l'ai corrigé, j'ai mis mon site Web en marche. :RÉ

J'ai eu ce problème et j'ai finalement réalisé que je 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 Pour plus d'informations, consultez le lien

avait le même problème. Si vous avez un certificat SSL installé sur IIS et si vous essayez de le déboguer à partir de Visual Studio, vous devez configurer votre application sur IIS pour ignorer le certificat.

J'ai eu le même problème et j'ai constaté qu'il était dû au fait que j'avais un caractère tapé par erreur dans mon Web.configaprès la balise de fin. Mon Web.configressemblait à ce droit à la fin: </section>h. Le "h" était un caractère supplémentaire après la balise de fermeture.

supprimez sting comme ceci: targetFramework = "4.0" dans web.config ou changez AppPool en version appropriée du framework.

La désinstallation de l'extension IIS UrlScan a résolu le problème pour moi.

J'avais rencontré le même problème, mais c'était sur le propre serveur de développement Web de Visual studios au lieu d'IIS. 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 consistait à supprimer manuellement le dossier bin et obj.

J'ai également trouvé ce problème, mais il était très similaire à 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>

Étant donné que les extensions de fichier .aspx n'étaient pas autorisées sur le serveur Web, l' /debugattach.aspxURL a été refusée, empêchant le débogueur de s'exécuter. Une fois que j'ai supprimé cette configuration, cela a fonctionné à nouveau.

J'ai eu le même problème lorsque j'ai créé une application dans Visual Studio, puis dans les propriétés, j'ai créé un répertoire virtuel à utiliser avec IIS local. Si quelqu'un a cette erreur, c'est parce que VS crée une application sous le mauvais AppPool, c'est-à-dire sous AppPool qui ne répond pas à vos besoins.
Si tel est le cas, allez dans IIS Manager, sélectionnez App, Go to Basic settings et changez AppPool for App et vous êtes prêt à partir.

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'en avais récemment ajouté deux 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 à nouveau les types MIME du site dans le cadre de mon processus de diagnostic que j'ai également eu une erreur dans IIS. Il faisait référence aux doublons dans web.config. Une fois que je suis retourné dans le fichier web.config, j'ai remarqué qu'une nouvelle section appelée avait été ajoutée, qui incluait les deux types MIME récemment ajoutés. Supprimé cette section et la vie est belle à nouveau! En espérant que cela peut aider d'autres personnes qui n'ont pas réussi à résoudre le problème avec l'une des autres suggestions.