Impossible de lancer le débogage sur le serveur web. Impossible de lancer le débogage ASP.NET VS 2010, II7, Win 7 x64

Question

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 lancer le débogage sur le serveur web. Impossible de lancer le débogage ASP.NET. De plus amples informations peuvent être obtenues en démarrant le projet sans débogage.

Malheureusement, le lien d'aide ne m'est pas d'un grand secours et me conduit à un très grand nombre de choses.

J'ai vérifié les points suivants :

• Exigences de sécurité - Je ne me souviens pas avoir eu à faire quoi que ce soit de spécial auparavant. Le processus de travail dans IIS7 est w3wp.exe. Il est indiqué que s'il est exécuté en tant que ASPNET ou NETWORK SERVICE, je dois disposer des privilèges d'administrateur pour le déboguer. Comment puis-je savoir si je dois modifier quelque chose ici ?

• La case Pages de propriétés du site Web > Options de démarrage > Débogueurs > ASP.NET est cochée. Utiliser le serveur personnalisé est défini sur l'URL du site (qui fonctionne bien sans débogage).

• Le débogage est activé dans web.config .

• L'application utilise ASP.NET 3.5 (je veux passer à 4.0 à terme mais j'ai quelques migrations à effectuer).

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

Une idée de l'endroit où je peux vérifier la prochaine fois ?

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

Merci d'avance.

Answer 1

Essayez d'accéder à IIS et vérifiez que le pool d'applications que vous utilisez est lancé. Souvent, vous obtiendrez une erreur qui arrêtera le pool d'applications. Il vous suffit de cliquer avec le bouton droit de la souris et de démarrer et vous devriez être prêt.

Answer 2

Il s'est avéré que le coupable était le IIS Réécriture d'URL module. J'avais défini une règle qui redirigeait les appels à Default.aspx (qui a été défini comme le page d'accueil du site web ) à la racine du site pour que je puisse avoir une URL d'accueil canonique. Cependant, apparemment, VS a eu un problème avec cela et s'est embrouillé. Ce problème ne s'est pas produit lorsque j'utilisais Helicon ISAPI_Rewrite et je n'ai donc pas pensé à vérifier.

J'ai fini par créer un tout nouveau site web en partant de zéro et en portant les projets/fichiers petit à petit dans ma solution et en reconstruisant mon web.config jusqu'à ce que je trouve cette solution ! Au moins, j'ai maintenant un site un peu plus propre en utilisant .NET 4.0 (jusqu'à présent, j'espère ne pas rencontrer de problèmes), mais quelle galère !

Answer 3

Visual Studio, au démarrage, va (pour une raison quelconque) tenter d'accéder à l'URL :

/debugattach.aspx

Si vous avez une règle de réécriture qui redirige (ou attrape autrement), disons, .aspx ailleurs, vous obtiendrez cette erreur. La solution consiste à ajouter cette section au début de votre fichier web.config 's <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 permettra de s'assurer que cette demande particulière sera prise en compte. rien et, surtout, arrêtez l'exécution afin qu'aucune de vos autres règles ne soit exécutée. Il s'agit d'une solution robuste, alors n'hésitez pas à la conserver dans votre fichier de configuration pour la production.

Answer 4

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 à une ressource réseau partagée. Depuis le dernier débogage de la solution, j'ai réinitialisé mon mot de passe Windows. J'ai changé le mot de passe stocké dans le pool d'applications et bada bing.

Answer 5

Pour mon scénario, il s'agissait de modifier la section httpErrors dans web.config, en la configurant comme suit :

<httpErrors mode="Custom"> 

a causé le problème "Impossible de démarrer le débogage sur le serveur web". En rétablissant la valeur précédente de "DetailedLocalOnly", le problème a été résolu. En creusant un peu plus, j'ai découvert que c'était en fait le paramètre d'erreur 401 qui était à l'origine du problème :

<httpErrors mode="Custom"> 
    <error statusCode="401" prefixLanguageFilePath="" path="/masterpages/500.html" responseMode="ExecuteURL" />
<httpErrors mode="Custom"> 

La mise en commentaire de la ligne d'erreur 401 a également permis de résoudre le problème. J'ai opté pour cette solution car je peux alors conserver la gestion personnalisée des erreurs et commencer le débogage.

Je ne sais toujours pas pourquoi cela se produit.