Erreur VS2010: impossible de démarrer le débogage sur le serveur Web
Je reçois le message d'erreur "Impossible de démarrer le débogage sur le serveur Web" dans Visual Studio 2010. J'ai cliqué sur le bouton Aide et suivi les suggestions associées sans succès.
Cela se produit avec un projet ASP.Net local nouvellement créé lorsqu'il est modifié pour utiliser IIS à la place de Cassini (qui fonctionne pour le débogage). Il vous est demandé de définir debug = "true" dans le fichier web.config, puis l'erreur apparaît immédiatement. Rien ne s'affiche dans l'observateur d'événements.
Je suis capable d'attacher à w3wp pour déboguer. Cela fonctionne mais n’est pas aussi pratique que F5.
J'ai également un problème similaire avec VS2008 sur le même PC. Le débogage fonctionnait pour les deux.
J'ai réenregistré Framework 4 (aspnet_regiis -i). J'ai exécuté la réparation VS2010 (il s'agit de la version RTM). J'exécute sur une boîte Windows Server 2008 R2 x64.
J'ai Resharper V5 installé.
Un paramètre de configuration ou une valeur de registre doit survivre à la réparation à l'origine du problème.
J'apprécierais toutes les idées.
J'ai un nouveau PC avec Windows 7. J'ai installé VS2010 et mon environnement de développement et espérais que mon problème de débogage F5 aurait disparu, mais le débogueur n'a toujours pas pu être démarré.
C’était un bon indice car il excluait l’installation de logiciels.
Je l'ai finalement tracé jusqu'à mon fichier HOSTS. J'avais accès à certains de mes sites Web locaux auxquels je pouvais accéder, par exemple " http: //testsite.lcl ", mais l'adresse IP que j'avais attribuée était celle de mon ordinateur plutôt que d'utiliser 127.0.0.1; VS2010. Revenir à 127.0.0.1 a résolu le problème.
Merci pour l'aide de tout le monde à ce sujet.
Désactiver la vérification en boucle
( page originale de Microsoft ici )
Pour définir la clé de registre DisableLoopbackCheck, procédez comme suit:
Cliquez sur Démarrer, sur Exécuter, tapez regedit, puis cliquez sur OK.
Dans l'Éditeur du Registre, recherchez et cliquez sur la clé de Registre suivante: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Cliquez avec le bouton droit sur Lsa, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
Tapez DisableLoopbackCheck, puis appuyez sur Entrée.
Cliquez avec le bouton droit sur DisableLoopbackCheck, puis cliquez sur Modifier.
Dans la zone Données de la valeur, tapez 1, puis cliquez sur OK.
Quittez l'Éditeur du Registre, puis redémarrez votre ordinateur.
J'ai eu le même problème. Comment l'ai-je réparé?.
Allez à IIS (dans mon cas IIS 7/Windows 7) . Sélectionnez votre site Web dans la liste, cliquez sur Compilation .NET dans la section ASP.NET. Sélectionnez Open Feature. Vérifiez si votre débogage est défini sur True. Dans mon cas c'était faux. Une fois que j'ai changé pour True - j'ai mon débogage en arrière :)
Ces étapes peuvent différer en fonction de votre version de Windows. J'utilise 7 avec iis 7.
Ouvrez le gestionnaire IIS, cliquez sur Pools d’applications et trouvez les 2 pools ASP.NET v4.0 (l’un s'appelle "ASP.NET v4.0", l’autre "ASP.NET v4.0 Classic"). Le premier est arrêté. Ne le démarrez pas encore, nous devons étudier un peu plus.
Pour le pool "ASP.NET v4.0", vérifiez le nom dans le champ d'identité. Est-ce ApplicationPoolIdentity? Souviens toi du nom.
Ouvrez Gestion de l'ordinateur (cliquez avec le bouton droit sur Poste de travail et sélectionnez Gérer). Développez Observateur d'événements, puis Journaux Windows. Cliquez sur Application et attendez que les données se chargent. Il devrait y avoir une erreur avec une source de service de profil utilisateur avec un message commençant par «Windows ne peut pas vous connecter car votre profil ne peut pas être chargé. Vérifiez que vous êtes connecté au réseau et que votre réseau fonctionne correctement».
Si vous trouvez cela, alors vous avez le même problème que moi.
La solution: Retournez dans IIS Manager, cliquez avec le bouton droit de la souris sur "ASP.NET v4.0" et sélectionnez Paramètres avancés. Sous Modèle de processus, le premier champ est Identité. Modifiez cela de ApplicationPoolIdentity à NetworkService. Cliquez sur OK.
Maintenant, démarrez le pool s'il n'a pas redémarré automatiquement. Retournez à votre application et appuyez sur F5 (démarrer le débogage) et votre application devrait fonctionner.
Veuillez noter que je n’ai pas compris pourquoi cela fonctionne, et que cela peut constituer un risque pour la sécurité, mais au moins, vous serez en mesure de travailler pendant que vous y réfléchissez.
J'ai eu ce problème dans Visual Studio 2012 lors de l'exécution d'un site Web créé dans Visual Studio 2010. J'ai essayé chacun des éléments suivants, qui ne résolvaient pas le problème, mais qui étaient peut-être nécessaires:
Vérifié que le pool d'applications était ciblé sur le même cadre que celui spécifié dans le fichier web.config
<compilation defaultLanguage = "c #" debug = "true" targetFramework = "4.0">
Démarrage du débogueur distant 64 bits:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Débogueur distant\x64\msvsmon.exe
Définissez la clé de registre DisableLoopbackCheck et redémarrez Windows. Instructions MS ici
J'ai parcouru le site localement (ça s'est très bien passé).
Enfin, j'ai trouvé le paramètre IIS qui corrigeait le problème.
- Accédez à IIS (7.5 dans mon cas) et cliquez sur le site correspondant dans le nœud Sites.
- Double-cliquez sur .NET Compilation dans la section ASP.NET
- Sous Comportement, définissez Debug sur True.
- Cliquez sur Appliquer et exécutez le site dans Visual Studio.
Vous pouvez d’abord déployer votre application/site Web avec vos iis, puis ouvrir votre visual studio 2010. Cliquez ensuite sur "Fichier" -> ouvrir -> site Web -> Site local IIS, puis sélectionnez votre site Web/votre application. Ensuite, vous constaterez que le débogage peut fonctionner. Cette méthode fonctionne pour mon cas.
J'ai eu le même problème sur Win7 et VS2010 (sans ReSharper) et j'ai constaté que Skype écoutait sur le port 80. IIS écoute le port 80 par défaut. Cela peut se produire lorsque vous configurez VS pour déboguer une application Web existante exécutée dans IIS au lieu du serveur Web de débogage ASP.NET intégré.
J'ai résolu le problème en décochant "Utiliser les ports 80 et 443 comme solutions de rechange pour les connexions entrantes". dans Skype sous Outils -> Options -> Connexion, puis redémarrez Skype.
Ce qui a fonctionné pour moi a été d'aller dans IIS au niveau du serveur, de cliquer sur les restrictions ISAPI et CGI. J'ai constaté que aspnet_isapi.dll pour asp.net 4.0 était défini sur Non autorisé. Je l'ai mis à permis et le débogage a fonctionné. Les étapes sont les suivantes:
- Ouvrez IIS.
- Cliquez sur le niveau supérieur
- Sélectionnez Restrictions ISAPI et CGI sous IIS dans la vue Fonctionnalités.
- Examinez les descriptions et si ASP.NET v4 [version actuelle] comporte la restriction non autorisée, cliquez sur le lien "Autoriser" dans la section Actions du dialogue.
Ce changement devrait régler le problème. Notez que j'ai trouvé cette solution lorsque j'ai essayé d'exécuter l'application Web sans débogage et que l'erreur suivante est apparue:
Erreur HTTP 404.2 - Introuvable La page que vous demandez ne peut pas être servie en raison des paramètres de liste de restrictions ISAPI et CGI sur le serveur Web.
Une autre chose à essayer (c'est ce qui a fonctionné pour moi):
Dans IIS, cliquez sur Pools d'applications> (Votre site)> Paramètres avancés, puis définissez "Activer les applications 32 bits" sur True.
Je n'ai pas de réponse précise, bien que ces articles puissent avoir des informations utiles:
Utilisation de Windbg pour commencer avec w3wp.exe Ceci mentionne spécifiquement les débogueurs de windbg/cdb, mais ce conseil devrait fonctionner avec Visual Studio qui parle à cdb (qui est attaché à w3wp).
Débogage distant avec Visual Studio La raison pour laquelle je parle du débogage distant, c'est que je devais l'utiliser plusieurs fois dans le passé pour que Visual Studio s'attache à w3wp.exe. W3wp.exe s'exécute dans une session différente, vous ne pouvez donc pas y attacher directement de débogueur.
Ce qui a fonctionné pour moi a été d’éditer le fichier HOSTS dans le dossier C:\Windows\System32\drivers\etc et de définir la boucle pour le nom du site Web que j’avais configuré.
Par exemple:
127.0.0.1 http://guyellisrocks.com/
Vous n'avez pas mentionné le système d'exploitation que vous utilisez. Mais cela pourrait ne pas être lié au système d'exploitation. Je suis en train de deviner. Si vous utilisez Windows 7, essayez d’exécuter Visual Studio sous Préfilages de l’administrateur.
Vous pouvez également essayer d'ajouter votre ID utilisateur au groupe d'utilisateurs du débogueur VS. Vous pouvez accéder aux groupes d'utilisateurs en cliquant de nouveau sur le nom de l'ordinateur ou sur mon ordinateur, puis en sélectionnant Gérer. Sous cela, vous pouvez trouver des utilisateurs et des groupes.
Je recevais cela après une nouvelle installation de Windows 7 qui n'incluait pas IIS par défaut. Après avoir installé IIS, le pool d'applications par défaut a été créé pour s'exécuter sous .NET 2.0. Bien que j'ai pu définir le pool d'applications par défaut sur .net 4 à partir de .net 2, j'ai quand même eu cette erreur. J'ai dû réinstaller .net 4 dans IIS pour que cela fonctionne correctement. Autrement dit, exécutez C:\Windows\Microsoft.NET {FrameworkFolder}\v {FrameworkNumber}\aspnet_regiis -i
Avez-vous modifié vos liaisons sur votre site Web IIS? Si tel est le cas, vous devez accéder aux propriétés de votre projet, sélectionner l'onglet Web et modifier l'URL du projet en fonction de votre liaison. alors où il est écrit http: /// yourwebsite le changer en http: /// yourwebsite
Cela a fonctionné pour moi.
Dans mon cas, c'est le system.webServer > httpErrors > errorMode dans le fichier web.config qui a causé le problème.
Si vous avez errorMode="Custom" essayez ceci:
<httpErrors errorMode="DetailedLocalOnly">
Voir cette réponse: https://stackoverflow.com/a/15585629/631277 pour les variantes et autres idées concernant la réécriture d'URL
Cela peut également être dû à un format spécial ou illégal dans votre fichier de configuration, je vous suggérerai de vérifier cela en premier.
Dans mon cas, j'ai eu une erreur à cause de cela lorsque j'ai essayé de naviguer dans mon service depuis IIS, il m'a montré la véritable erreur.
Après avoir essayé toutes les solutions ci-dessus, je continuais à avoir ce problème. D'autres projets déboguaient sans problème, alors je savais que cela devait être lié à la configuration de cette application particulière.
Le mien est une application MVC fonctionnant sous IIS 8. Le problème était avec la réécriture d'URL.
J'avais une règle pour appliquer les barres obliques de fin. Tout ce que j'avais à faire était de le désactiver (ce qui peut être fait directement dans IIS ou via le fichier web.config ci-dessous - il suffit de définir enabled = "false")
<rewrite>
<rules>
<rule name="AddTrailingSlashRule1" enabled="false" stopProcessing="true">
<match url="(.*[^/])$" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
</conditions>
<action type="Redirect" url="{R:1}/" />
</rule>
</rules>
</rewrite>
Déchargez le projet, cliquez avec le bouton droit de la souris sur "edit abc.csproj". La configuration s'affichera. Si votre projet est mappé pour utiliser IIS l'URL Web Express.
<WebProjectProperties>
<UseIIS>True</UseIIS>
<AutoAssignPort>True</AutoAssignPort>
<DevelopmentServerPort>6270</DevelopmentServerPort>
<DevelopmentServerVPath>/</DevelopmentServerVPath>
<IISUrl>http://matrimonyfree.in/</IISUrl>
<NTLMAuthentication>False</NTLMAuthentication>
<UseCustomServer>False</UseCustomServer>
<CustomServerUrl>
</CustomServerUrl>
<SaveServerSettingsInUserFile>False</SaveServerSettingsInUserFile>
</WebProjectProperties>
vérifiez si vous avez démarré le site Web dans IIS http://matrimonyfree.fr dans ce cas
Vérifiez si le fichier msvsmon.exe (moniteur de débogage Visual Studio distant) est présent dans le chemin ci-dessous: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x64
Si le fichier ne persiste pas dans le chemin mentionné ci-dessus, vous devez vous le procurer à partir de tout autre ordinateur disposant de la même version de Visualstudio.
J'ai eu le même problème et dans mon cas, c'est parce que l'identité de AppPool était définie pour emprunter l'identité d'un utilisateur AD dont le mot de passe avait été modifié. Par conséquent, le processus n'a pas pu démarrer et l'AppPool s'est toujours arrêté lors de la tentative de débogage à partir de VS.
Après la mise à jour du mot de passe dans AppPool/Paramètres avancés/Identité, tout a commencé à bien fonctionner.
J'ai essayé chaque solution mise en ligne pour résoudre ce problème et rien ne semble fonctionner de manière cohérente.
Je l'ai finalement résolu en 2010 et 2012 en le localisant jusqu'au fichier manquant suivant dans le paramètre Fichiers sources de débogage
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\atlmfc\src\mfc\
Solution> Propriétés> Fichiers sources de débogage>
Vérifiez que tous les fichiers sont présents, puis supprimez cette entrée et tout fonctionne à nouveau.
Impossible de démarrer le débogage sur le serveur Web. le serveur Web n'est pas configuré correctement.
Comment résoudre ce problème?
Étape 1
ouvrir l'invite de commande (exécuter en tant qu'administrateur)
Étape 2
C:\Windows\system32> cd ..
C:\Windows> cd Microsoft.NET
C:\Windows\Microsoft.NET> cd Framework
C:\Windows\Microsoft.NET\Framework> cd v4.0.30319
C:\Windows\Microsoft.NET\Framework\v4.0.30319> aspnet_regiis.exe -i
J'ai eu le même problème avec Visual Studio 2013. Dans mon cas, j'avais supprimé le "site Web par défaut" d'IIS. Pour résoudre le problème, j'ai créé à nouveau le site Web par défaut, définissez le chemin d'accès physique sur C:\inetpub\wwwroot et port sur 80 (port par défaut). Après avoir redémarré Visual Studio, cela a parfaitement fonctionné. J'espère que ça aide quelqu'un.
Dans IIS dans l'onglet Sécurité du répertoire, si vous utilisez SSL, cochez la case "Ignorer le certificat client" si vous l'exécutez sur votre PC local.