Je viens d’essayer de déployer ma première application Web sur IIS sur mon ordinateur portable Windows 7 Home Premium. Après avoir créé l'application, je devais passer au pool d'applications Classic, puis définir ce pool pour Framework 4.0. Maintenant, j'obtiens l'erreur suivante:
Erreur HTTP 404.17 - Introuvable Le contenu demandé semble être script et ne sera pas servi par le gestionnaire de fichiers statiques.
L'URL demandée est http: // localhost: 80/pvmms/default.aspx
Je crains que de nombreuses recherches sur Google n'aient abouti à un résultat suffisamment clair ou défini pour que je puisse travailler avec et, comme d'habitude, je me suis tourné vers les experts.
EDIT: Je suppose que c'est parce qu'il n'y a pas de mappages de gestionnaires framework 4.0 pour les fichiers .aspx. Cependant, aspnet_regiis donne même le doigt à mon administrateur et lui dit que j'ai besoin des droits d'administrateur pour l'exécuter.
EDIT # 2: J'ai enregistré tous les frameworks (2 & 4, 32 et 64) et tout fonctionne maintenant. J'ai trouvé cela en ajoutant manuellement une mappe de script pour .aspx
à aspnet_isapi et le tour est joué. Je ne comprends pas pourquoi l'installation du framework ne le fait pas, à moins que ma mémoire ne me manque et que je n'active que IIS après l'installation de VS.
Peut-être trop tard maintenant, mais le plus souvent, vous devez courir
aspnet_regiis.exe -i
après avoir installé asp.net. Peut-être que je le ferais de toute façon maintenant.
En plus de ce qui précède, si vous avez besoin du support de WCF, vous devrez peut-être exécuter ceci:
c:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\ServiceModelReg.exe -i
Remplacez la v3.0 par la version actuelle de votre infrastructure.
J'ai rencontré cette erreur de IIS 8.5 en essayant d'accéder à un service WCF que j'avais écrit. Il s'avère que le serveur n'avait pas activé les fonctionnalités d'activation HTTP WCF. Coche les cases et clique sur l'assistant, iisreset, a commencé à fonctionner.
Si vous utilisez iis 7.5.
Allez simplement dans IIS Manager, ouvrez les propriétés de votre site Web.
Vous verrez la section 'Handler Mappings', allez dans cette section et cherchez 'staticFile'.
C'est probablement un dernier fichier de la liste.
Puis faites un clic droit dessus et sélectionnez 'Revert To Parent'.
J'ai perdu tellement d'heures à faire face à cette première fois, de toute façon, cela résoudra votre problème.
J'ai eu ce problème avec Windows Server 2012 avec ASP .NET 4.5. Vous ne pouvez pas utiliser aspnet_regiis.exe. Vous devez simplement installer ASP .NET 4.5 via l'Assistant Ajouter des rôles et des fonctionnalités. :
Vous pouvez trouver l'élément de menu "Ajouter des rôles et des fonctionnalités" dans le menu "Gérer", dans le coin droit du Gestionnaire de serveur.
Je sais que c’est une vieille question, mais je viens de le faire avec une application 3.5 sur ma machine Windows 8 reconstruite et je l’obtenais toujours après le aspnet_regiis -iru
. Caractéristiques (pas assez de réputation pour publier une image).
devrait vérifier cette option je suppose
J'ai résolu ce problème en activant WCF Services
Programs and Features > NET Framework 4.5 Services > WCF Services> HTTP Activation node
Mais vous devez admettre que c’est TOUT le monde IIS configurez/suppose/trial et voyez/essayez ce/essayer qui passe 4 ou 5 de nos jours à essayer de trouver une solution autour de l’approche IS UN FOUET COMPLET ET TOTAL.
SÛREMENT, 'IIS' IS LE PLUS GRAND ÉCHEC DE CONFIANCE JAMAIS JOUÉ SUR L'HOMME À JOUR
Il se peut que le pool d’applications créé pour votre application par défaut soit la version 2. Par conséquent, bien que vous voyiez un gestionnaire pour l’extension .svc dans la liste, il ne fonctionne pas et le traite comme un fichier statique. Tout ce dont vous avez besoin est d'ouvrir les propriétés du pool d'applications et de passer à la version 4.
Enregistrez à nouveau asp.net ... va résoudre le problème.
Accédez à l'invite de commande de Visual Studio,
Et enregistrez asp.net en tant que windows\Microsoft.net\Framework [numéro de version. Net]\aspnet_regiis.exe -i
J'ai eu le même problème sur une machine Windows 8 que je suis en train d'installer. J'avais déjà installé vs2012 avant vs2010, qui installe .NET Framework 4.5. J'ai mes pools d'applications fonctionnant en 4.0. Je me suis assuré d’avoir aspnet enregistré pour la version 4.0 en utilisant aspnet_regiis -i. Cela n'a toujours pas fait l'affaire. Ensuite, j'ai ouvert les fonctionnalités Windows et remarqué que la version 4.5 ajoutait un ensemble appelé "Services avancés .NET Framework 4.5". J'ai activé le noeud de service WCF et ses enfants, puis mon noeud final svc a fonctionné correctement. J'espère que cela aidera les personnes qui migrent vers Windows 8.
Je suis tombé sur cette question lorsque je me suis heurté au même problème. La cause première de mon problème était un pool d'applications mal configuré. Il a été paramétré sur 2.0 par inadvertance, alors qu'il devait être défini sur 4.0. La réponse au lien suivant m'a aidé à découvrir ce problème: http://forums.iis.net/t/1160143.aspx
Pour d'autres personnes lisant ceci:
Cela peut arriver si la version .Net que vous avez enregistrée n'est pas celle sélectionnée dans les "Paramètres de base" du pool d'applications attaché à votre site Web. Par exemple, .Net v2.0 est sélectionné dans votre pool d’applications de sites, mais vous avez enregistré v4.0.
J'ai eu le même problème. Lorsque j'ai ajouté la fonctionnalité de contenu statique pour IIS, cela fonctionne bien.
Juste une autre solution possible que j'ai trouvée ayant le même message d'erreur.
Lors de la tentative d'installation d'une application Web .NET 4.0 dans un nouveau pool d'applications, je recevais cette étrange erreur en me disant qu'il essayait de traiter mon fichier aspx avec le gestionnaire de fichiers statiques, ce qui n'avait aucun sens.
Pour une raison quelconque, ISAPI pour .NET 4.0 a été défini sur Désactivé dans la zone Restrictions ISAPI et CGI du niveau du serveur dans le gestionnaire IIS. Il suffisait de l'activer pour pouvoir l'activer . Cependant, le gestionnaire IIS 7.5 est si compliqué et difficile à suivre qu'il m'a fallu beaucoup de temps pour comprendre cela.
Je suppose que puisqu'il s'agissait d'une application 4.0 qui ne pouvait pas être traitée par le moteur 4.0, le gestionnaire de fichiers statiques était utilisé par défaut.
Pour Windows 10/Framework 4.7, je devais activer l'activation HTTP à l'aide de la méthode suivante:
cmd -> clic droit -> Exécuter en tant qu'administrateur
C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -i
En utilisant le gestionnaire IIS, j'ai constaté que les fichiers .aspx étaient mappés (sous "Mappages de gestionnaires") vers ISAPI 2.0 - même si ASP.NET 4.5 avait été précédemment installé. Les éditer pour pointer (également) vers un exécutable pour ISAPI 4.0 64 bits a résolu le problème.
L'exécutable a été trouvé dans % Windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll
J'ai eu le même problème, je viens de changer la version du framework cible sur le site Web pour la version dans laquelle elle est développée, identique dans IIS. Cela a résolu mon problème. J'espère que cela t'aides...
Je vous remercie
j'ai reçu ce message pour une application sur iis 7.5 avec un pool d'applications classiques affecté à .net 2.0. J'avais besoin d'aller à Handler Mappings et d'ajouter deux cartes de script, les deux étaient les mêmes avec l'exception du nom. l'un s'appelait svc-ISAPI-2.0-64, l'autre svc-ISAPI-2.0. Le chemin de la demande était .svc. Et l'exécutable était% SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll. J'ai redémarré IIS et tout était heureux
il peut y avoir plusieurs raisons, dans mon cas sous Pool d'applications-> paramètres avancés-> Activer l'application 32 bits (doit être true) .Il était défini sur false auparavant.
L'un des pires scénarios que je viens de résoudre est d'avoir une entrée conflictuelle dans Web.config.
Sur mon ordinateur local, l'extension .woff n'était pas enregistrée dans IIS, je l'ai donc ajoutée à l'aide de Web.config. Mais sur le serveur de production .woff avait le type mime enregistré. Cela a provoqué un conflit au niveau de l'application.
La partie drôle est qu'il n'y a aucune erreur enregistrée pour ceci. Juste un travail de devinette (première fois bien sûr).
Pour moi, la solution consistait donc simplement à supprimer et/ou des éléments de web.config.