Le serveur Web n'a pas pu trouver la ressource demandée
J'ai une application Web .NET 3.5 sur VS 2008 SP1 sous Vista Ultimate 32 SP1. J'ai créé une application sur le site Web par défaut. Donc, l'URL de l'application est " http: // localhost/mysite ". Le dossier de l'application pointe vers le dossier de la solution et il se trouve en dehors du dossier iisroot. L'authentification anonyme et intégrée (Windows) est activée dans IIS7 pour cette application Web "mysite".
J'ai donné des autorisations complètes à l'utilisateur "Service réseau" pour le dossier de l'application (qui est en dehors de iisroot).
Lorsque j'appuie sur F5 pour lancer le débogage en étoile, le message "Impossible de démarrer le débogage sur le serveur Web s'affiche. Le serveur Web n'a pas pu trouver la ressource demandée". Erreur.
J'ai lancé TcpView (Sysinternals) pour voir quelle application est en cours d'exécution et conserver une poignée sur ce port. J'ai découvert qu'aucune application n'écoutait ce port. C'est vraiment bizarre ... Des idées créatives?
Je peux cliquer sur l'URL " http: // localhost/mysite " sans problème. Cette application Web est configurée pour être le projet de démarrage et Default.aspx, la page de démarrage.
Il existe également un service .asmx dans le projet. Default.aspx utilise ce service asmx. AutoCompleteExtender (à partir du AJAX Control Toolkit) utilise ce service asmx.
Tout fonctionne au passage. Le problème est le débogage ... Je suppose que le service asmx est la cause, mais je ne sais pas. Ça me rend dingue...
Pour ceux qui rencontrent ceci avec Visual-Studio 2012 ou 2013 et/ou Windows 8 ou 10 , procédez comme suit.
Vous devez ajouter .Net 3.5 (ou 4.5) à votre Activer ou désactiver les fonctionnalités Windows fenêtre. Vous y arrivez via:
Panneau de configuration -> Programmes -> Activer ou désactiver des fonctionnalités Windows
Cochez les cases Asp.Net 3.5 et Asp.Net 4.5 dans le dossier IIS > WWW Service > Application Development Features.
ouvrez IIS7 (run> inetmgr) et accédez à la vue Fonctionnalité. Ouvrez la section Restrictions ISAPI et CGI et vérifiez si votre version .Net dispose de la restriction appropriée (par exemple, si vous travaillez avec la version 4.0, il doit être sur "Autorisé")
Un autre problème courant est que le chemin du site ou de l'application n'est pas démarré.
J'ai eu le même problème et l'ai résolu. Vous pouvez essayer de suivre les étapes suivantes: accédez au dossier racine de votre application Web et recherchez le fichier portant l’extension ".csproj.user" et supprimez-le. Fermez toutes les instances de Visual Studio et recommencez. Puis appuyez sur F5. Sinon, appuyez sur CTRL + ALT + P et attachez-le au processus w3wc.exe. J'espère que ça aide.
J'ai juste réussi à résoudre ce problème sur ma machine de développement: UrlScan est installé et j'ai dû ajouter DEBUG à la liste de AllowVerbs. Espérons que cela pourrait vous donner autre chose à continuer?
L'installation de Urlscan et la modification du fichier urlscan.ini avec ces modifications ont résolu le problème.
Dans la section ALLOWEXTENSIONS, ajoutez .aspx et dans la section ALLOWVERBS, ajoutez DEBUG.
N'oubliez pas de redémarrer IIS.
J'avais le même problème avec XP sp3 et je me débattais depuis des jours. Ajouter .aspx et DEBUB à urlscan.ini a résolu le problème.
Merci les gars.
Dans mon cas, j'ai dû ré-enregistrer ASP.NET pour IIS. Vous pouvez le faire en exécutant la commande suivante à partir de la commande Invite
systemroot\Microsoft.NET\Framework\ versionNumber \aspnet_regiis -i
par exemple: C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis -i
pour moi, le site Web par défaut dans IIS a été arrêté. Après l'avoir démarré, j'ai réussi à le faire fonctionner.
Dans mon cas, j'ai dû réparer les extensions de service Web.
Outils d'administration -> Gérer mon serveur -> IIS -> Extensions du service Web
ASP.NET 2.0 était interdit d'une manière ou d'une autre, cela a été corrigé et cela a commencé à fonctionner.
À votre santé!
J'utilise Windows 7 32 bits avec VS2005 et IIS 7.5. Mon web.config avait debug = "true" par défaut. J'ai configuré le chemin physique IIS pour qu'il pointe vers le dossier de développement et ai suivi les conseils ci-dessus. Je n'utilise pas UrlScan. Je cours VS2005 en tant qu'administrateur. Je ne pouvais toujours pas le faire fonctionner.
Ce qui a fonctionné, c’est l’ajout du compte IIS_IUSRS avec un accès complet au dossier racine du site Web de développement et l’utilisation de CTRL + ALT + P (processus d’attachement) pour attacher à w3wp.exe.
Pour moi, quelqu'un avait mis à jour le fichier web.config pour le filtrage des demandes, en particulier, il autorisait uniquement les verbes GET et POST. Pour utiliser local IIS, vous devez également autoriser le verbe DEBUG.
<verbs allowUnlisted="false">
<add verb="GET" allowed="true" />
<add verb="POST" allowed="true" />
<add verb="DEBUG" allowed="true"/>
</verbs>
J'utilisais aussi le site Web par défaut sur IIS, mais je n'ai pas été en mesure de le lancer par débogage ou par simple navigation.
Il s'est avéré que le site par défaut a été arrêté !! Commencé, et tout va bien.
La solution à ce problème est assez simple. Si le site Web pointe vers un emplacement différent et si le répertoire virtuel pointe vers un autre répertoire, vous recevrez cette erreur.
Je suggère que vous pointez le site Web vers le même répertoire que le répertoire virtuel et le problème suffira.
Cela ne devrait pas être un problème - qu'est-ce que vous avez comme page de démarrage? De même, dans les "Options de démarrage" du Web (sous la page de propriétés), assurez-vous que "URL de départ" est sélectionné et placé dans l'URL mentionnée ci-dessus.
L’erreur que vous rencontrez ne devrait pas être spécifique à une permission, donc je chercherais ailleurs - vérifiez également si vous pouvez appuyer sur l’URL avant de déboguer (le manuel met l’URL dans votre navigateur) " http: // localhost/mysite " .
Je viens d'avoir ce même problème et aucune des suggestions n'a fonctionné.
Mon problème était que l'URL de mon projet était définie sur http://localhost/service. Changer cela en mon adresse IP a fonctionné.
Accédez aux propriétés de votre projet Web, puis à l'onglet "Web", puis vérifiez que vous utilisez le serveur de développement Visual Studio et non Local IIS ou le serveur Web personnalisé. Je suis sur VS2010 avec Win7 et un autre développeur développait en utilisant une URL de serveur Web personnalisée et non le serveur de développement VS
As-tu essayé:
- Tour d'UAT
- Ajoutez l'utilisateur (et/ou vous-même) sous le site Web au groupe de débogueurs ou d'administrateurs (temporairement)
- Activer la journalisation IIS
Juste pour vous en assurer, avez-vous configuré Debug = true dans votre web.config. Généralement, lorsque vous utilisez le serveur Web intégré de VS, il est alors capable de détecter que vous essayez de déboguer, mais le drapeau de débogage est désactivé et vous en avertit. Mais dans votre cas, vous avez configuré IIS et VS ne pourra peut-être pas effectuer cette vérification.
Un autre point est que vous utilisez Vista. Dans Vista, même si vous êtes l'administrateur du système, Vista ne vous traite pas comme administrateur. Vos jetons de sécurité sont créés en tant qu’utilisateur normal. Pour effectuer le débogage IIS site Web hébergé (remarque: si vous utilisez un serveur Web intégré, VS 2008 gère le débogage), exécutez VS 2008 en tant qu'administrateur. Cela pourrait résoudre le problème.
J'ai tout essayé en vain, mais une fois que j'ai sorti le fichier csproj.user, le site est chargé. Ne vous inquiétez pas pour le supprimer, dès que le site sera chargé, il en créera un nouveau.
J'ai le même problème, mais je peux déboguer si je vais via le menu Outils -> Attacher au processus puis sélectionnez le processus aspnet_wp.
Assurez-vous que l'URL du projet dans l'onglet Web des propriétés du projet ne contient pas de caractères non valides. Dans mon cas, il y avait un caractère "+", ce qui a provoqué l'apparition de cette erreur.
Cette section de mon web.config a provoqué l'erreur:
<security>
<requestFiltering>
<hiddenSegments>
<add segment="......" />
<add segment="....." />
........
</hiddenSegments>
</requestFiltering>
</security>
Révisez-le soigneusement - votre fichier de débogage est peut-être limité à l'affichage direct dans le navigateur.