Problèmes d'application Web (erreurs web.config) HTTP 500.19 avec IIS7.5 et ASP.NET v2
Cela rend toute l'équipe folle. Il doit exister une simple partie mal configurée de IIS ou de notre serveur Web, mais chaque fois que nous essayons d'exécuter une application Web ASP.NET sur IIS 7.5, nous obtenons l'erreur suivante. ..
Voici l'erreur en entier:
_HTTP Error 500.19 - Internal Server Error
The requested page cannot be accessed because the related configuration
data for the page is invalid.
`Detailed Error Information`
Module IIS Web Core
Notification Unknown
Handler Not yet determined
Error Code 0x8007000d
Config Error
Config File \\?\E:\wwwroot\web.config
Requested URL http://localhost:80/Default.aspx
Physical Path
Logon Method Not yet determined
Logon User Not yet determined
Config Source
-1:
0:
_La machine est en cours d'exécution Windows Server 2008 R2. Nous développons notre application Web en utilisant Visual Studio 2008.
Selon Microsoft, le code 8007000d signifie qu'il existe une erreur de syntaxe dans notre fichier web.config - à l'exception du projet construit et exécuté localement. Regarder le web.config dans XML Notepad ne fait apparaître aucune erreur de syntaxe non plus. Je suppose que cela doit être une sorte de mauvaise configuration de ma part ...?
Est-ce que quelqu'un sait où je pourrais trouver d'autres informations sur l'erreur? Rien ne s'affiche dans EventViewer, que ce soit :(
Je ne sais pas quoi d'autre serait utile de mentionner ...
L'assistance est grandement appréciée. Merci!
MISES À JOUR! - PUBLIÉ WEB.CONFIG CI-DESSOUS
Ok, depuis que j'ai posté la question originale ci-dessus, j'ai repéré les lignes précises dans le web.config qui étaient à l'origine de l'erreur.
Voici les lignes (elles apparaissent entre les balises _<System.webServer>_) ...
_ <httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</httpHandlers>
_Remarque: Si je supprime les lignes entre et le _<httpHandlers>_, j'obtiens encore l'erreur. Je dois littéralement supprimer _<httpHandlers>_ (et les lignes entre les deux) pour ne plus avoir l'erreur ci-dessus.
Une fois que j'ai fait cela, j'obtiens cependant une erreur nouvelle 500.19. Heureusement, cette fois IIS me dit quel bit de web.config est à l'origine du problème ...
_ <handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory,System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</handlers>
_En regardant ces lignes, il est clair que le problème a migré davantage au sein de la même balise _<system.webServer>_ vers la balise _<handlers>_.
La nouvelle erreur est également plus explicite et se plaint spécifiquement de ne pas reconnaître l'attribut "valider" (comme indiqué à la troisième ligne ci-dessus). En supprimant cet attribut, on se plaint alors que la même ligne ne possède pas l'attribut "nom" requis. Ajouter cet attribut fait alors apparaître ASP.NET erreur ...
Impossible de charger le fichier ou l'assembly 'System.web.Extensions, Version = 1.0.61025.0, Culture = neutre, PublicKeyToken = f2cb5667dc123a56' ou l'une de ses dépendances. Le système ne trouve pas le fichier spécifié.
Évidemment, je pense que ces nouvelles erreurs viennent de découler de la suppression des balises <httpHandlers> - elles sont évidemment nécessaires à l'application - la question reste donc: pourquoi Les balises déclenchent une erreur dans IIS en premier lieu ???
Dois-je installer quelque chose sur IIS pour le faire fonctionner avec eux?
Merci encore pour toute aide.
WEB.CONFIG
Voici les morceaux gênants de notre web.Config ... J'espère que cela aide quelqu'un à trouver notre problème!
_<system.Web>
<!-- stuff cut out -->
<httpHandlers>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add verb="*" path="*_AppService.axd" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56" validate="false"/>
</httpHandlers>
<httpModules>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</httpModules>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<modules>
<add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</modules>
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<handlers>
<remove name="WebServiceHandlerFactory-Integrated"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory,System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
<add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=f2cb5667dc123a56"/>
</handlers>
</system.webServer>
_Aha! J'ai vaincu ce problème! Mon dieu, c’était une bête pour quelqu'un comme moi avec une IIS expérience limitée. Je pensais vraiment que je passerais tout le week-end à le réparer.
Voici la solution pour quiconque rencontre ce problème pervers.
Première chose à savoir: si vous espérez que ce sera votre solution, assurez-vous que vous avez le même code d'erreur ( 0x8007000d ) et la source de configuration. ( - 1: 0: ). Sinon, ceci n'est pas votre solution.
La prochaine chose à savoir: AJAX n'est pas correctement installé dans votre web.config!
Corrigez cela en suivant ce guide:
http://www.asp.net/AJAX/documentation/live/ConfiguringASPNETAJAX.aspx
Ensuite, installez les extensions AJAX 1.0 sur votre serveur de production, à partir de ce lien:
http://www.asp.net/ajax/downloads/archive/
Mise à jour : Microsoft semble avoir supprimé la page ci-dessus: (
C'est ça!
J'ai eu ces symptômes exacts et mon problème était semblable à celui de Peter. Établissait un projet existant sur un nouveau serveur. Mon projet faisait référence au module de réécriture d'URL IIS7, mais cela n'avait pas encore été installé sur le nouveau serveur. L'installer a corrigé mon problème.
Vous pouvez utiliser le programme d'installation de la plate-forme Web Web pour l'installer. Exécutez-le, sélectionnez Produits , dans le menu de gauche, sélectionnez Serveur et recherchez l'URL réécrite dans la liste et installez-le.
Ou vous pouvez le télécharger ici .
Après avoir lutté avec cela pendant une journée sur une nouvelle machine, je suis tombé sur les liens suivants. Il me manquait les modules de réécriture. Cela a tout corrigé.
http://forums.iis.net/t/1176834.aspx
http://learn.iis.net/page.aspx/460/using-the-url-rewrite-module/
Même problème sur Server 2016, IIS 10, erreur 500.19. J'ai installé le module de redirection et cela a fonctionné. Je ne sais pas pourquoi cela n'a pas été inclus par défaut.
https://www.iis.net/downloads/Microsoft/url-rewrite#additionalDownloads
Pour être clair, il semble que le script web.config de IIS 7 fonctionne ou est conçu pour fonctionner, mais l’absence de ce module donne une erreur vraiment étrange et peu utile. Googling vous amène à une page Microsoft qui insiste sur le fait que votre site est corrompu ou que votre web.config est corrompu. Ni semble être le cas.
Cette page inutile est ici: https://support.Microsoft.com/en-us/kb/942055
Nous avions le même problème que ci-dessus, le même code d'erreur, etc. Configuration d'un site Web local sous Windows 8. Après de nombreuses recherches, il nous est apparu qu'il nous manquait la réécriture d'URL. Après le téléchargement, tout allait bien. :)
J'ajoute simplement une tenue de soirée parce que j'ai passé des heures à essayer de résoudre les mêmes symptômes (mais un problème différent):
Une cause possible est une DLL x86 dans un pool d'applications 64 bits. La solution consiste à activer les applications 32 bits dans les paramètres du pool d'applications.
Pour moi, ré-enregistrer asp.net pour iis a fait l'affaire. Espérons que cela aide quelqu'un d'autre.
aspnet_regiis.exe -i
Pour résumer en fonction des réponses ici et ailleurs:
- Vérifier la version .NET du pool d'applications (par exemple 2.0 vs 4.0)
- Vérifiez que tous les IIS modules référencés sont installés. Dans ce cas, il s’agissait des extensions AJAX (ce n’est probablement plus le cas de nos jours), mais RL Rewrite est une extension courante.
Une autre façon d'obtenir l'errot 500.19 sans raison apparente consiste à - supprimer des répertoires et/ou des autorisations brisées.
Dans le cas de cette question, je pense que la question concerne la version complète IIS. Je suppose cela à cause de cette ligne:
Config File \\?\E:\wwwroot\web.config
Le programme d'installation IIS crée généralement le fichier wwwroot pour vous. Il s'agit du dossier racine par défaut pour tous les sites Web et du point de montage pour les répertoires virtuels. Cela existe toujours, alors pas de problème, vous ne vous souciez généralement pas beaucoup de cela.
Comme les fichiers web.config sont hiérarchiques, vous pouvez y placer un fichier maître web.config et y définir des paramètres racine. Tous les sites en hériteront. IIS vérifie si ce fichier existe et essaie de le charger.
Cependant, première partie amusante:
Ce répertoire existera si vous avez correctement installé IIS. S'il n'existe pas, vous obtiendrez une erreur de 500 classes. Cependant, si vous jouez avec des permissions de fichiers/répertoires, en particulier "avancées", vous pouvez accidentellement refuser IIS compte de service de scanner/lire le contenu de ce répertoire. Si IIS ne peut pas vérifier si ce wwwroot\web.config existe ou s'il existe et si IIS ne peut pas l'ouvrir et le lire - bam - erreur de classe 500.
Cependant, pour les IIS complets, il est très peu probable. Les développeurs/administrateurs travaillant avec IIS complet hésitent généralement à jouer avec wwwroot, de sorte qu'il reste généralement configuré correctement.
Cependant, sur IIS Express ..
Habituellement, IIS Express "ne fonctionne que". Souvent, les développeurs qui utilisent IIS Express ne savent pas combien, en interne, cela ressemble au véritable IIS.
Vous pouvez facilement tomber sur le fait que IIS Express a son propre fichier applicationHost.config et que VS le crée et le gère pour vous (correctement, dans une certaine mesure) et ce genre de révélation vous indiquant que c'est pas si simple et pointer-cliquer comme cela semble au premier abord.
En plus de ce fichier de configuration, VisualStudio crée également une structure de répertoire vide dans votre dossier Documents. Si je me souviens bien, IIS Express considère ces dossiers comme étant les répertoires racine de votre/vos site (s) sur lesquels les répertoires virtuels avec votre code sont montés.
Plus tard, tout comme IIS, lorsque IIS Express démarre, il attend l'existence de ces dossiers et recherche les fichiers racine Web.config. Là. Les fichiers du site web.config . Presque toujours, ces fichiers web.config sont manquants - et c’est bien parce que vous ne les voulez pas - vous avez votre ** application web.config ", ils sont placés avec le reste du contenu dans des répertoires virtuels.
La deuxième partie amusante est la suivante: IIS Express attend que des répertoires vides. Ils peuvent être vides, mais ils doivent exister. S'ils n'existent pas, vous obtiendrez une erreur de 500 classes vous indiquant que le fichier "web.config" situé sur ce chemin est inaccessible.
La première fois que je suis tombé sur ce problème, c’était quand je nettoyais mon disque dur. J'ai découvert ce dossier 'documents\sites Web', plein de corbeille, j'ai reconnu plusieurs projets vieux de plusieurs années sur lesquels je ne travaille plus, tous vides, pas un seul fichier, alors je les ai tous supprimés. Une semaine plus tard - bam - je ne peux pas exécuter/déboguer aucun des sites sur lesquels je travaillais en ce moment. Erreur était 500.19, impossible de lire le fichier de configuration.
Ainsi, si vous utilisez IIS Express et que vous voyez une erreur indiquant 500 classes sur la lecture de la configuration, vérifiez attentivement le message d'erreur et lisez tous les chemins mentionnés. Si vous voyez quelque chose comme:
c:\users\user\documents\visual studio 2013\projects\WebProject1\WebProject1.web\web.config
c:\users\zeshan.munir\documents\visual studio 2015\projects\WebProject1\WebProject1.web\web.config
c:\users\zeshan.munir\documents\visual studio 2017\projects\WebProject1\WebProject1.web\web.config
etc..
Allez exactement là où l'erreur indique, assurez-vous que ces dossiers existent, assurez-vous que le compte d'utilisateur IIS peut les parcourir et les lire, et si vous remarquez que quelque chose ne va pas, peut-être que ce sera le cas.
BTW. Dans VisualStudio, sur ProjectProperties/Web, un bouton "Créer un répertoire virtuel". Il fait essentiellement cela, donc vous pouvez l'essayer en premier, mais IIRC peut aussi effacer/remplacer/échanger les sections de configuration dans le fichier applicationHost.config, soyez donc prudent avec ce bouton si vous avez des configurations personnalisées.
Dans mon cas, il y avait un problème avec l'installation de .NET Core Windows Hosting Bundle.
J'avais installé et redémarré IIS avec ("net stop was/y" et "net start w3svc") après l'installation, mais j'obtiendrais cette erreur 500.19 avec le code d'erreur 0x8007000d et la source de configuration -1: 0 :.
J'ai réussi à résoudre le problème en réparant l'installation du pack d'hébergement Windows .NET Core et en redémarrant IIS à l'aide des commandes que j'ai mentionnées ci-dessus.
J'espère que ça aide quelqu'un!
J'ai eu la même erreur. J'avais un site IIS avec .net Framework version 2.0, mais mon application nécessitait 4.0. J'ai changé la version et cela a fonctionné.
Publier juste comme rappel si quelqu'un pourrait avoir le même problème.
Commentez les lignes suivantes dans le fichier web.config.
<modules>
<!--<add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->
</modules>
<handlers>
<remove name="WebServiceHandlerFactory-ISAPI-2.0"/>
<!--<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
<add name="ScriptResource" verb="GET" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>-->
</handlers>
Cela fonctionnera.
Mon IIS 7.5 ne comprend pas la balise dans web.config Dans VS 2010, cette balise est également soulignée. Vérifiez votre fichier de configuration avec précision pour trouver toutes les balises soulignées. Je le mets dans le commentaire et l'erreur disparaît.
Cette belle erreur détaillée est toujours présente en 2019! Je veux juste ajouter que si votre web.config est valide et accessible, il s'agit probablement d'un problème de dépendance.
Comme mentionné par l'OP, il s'agissait d'un module AJAX et, comme d'autres, généralement du module Rewrite. Gardez simplement les yeux ouverts dans votre web.config à quels modules et à quelles bibliothèques vos balises font référence depuis le code d'erreur x8007000d peut être à propos de TOUTE dépendance.
Dans mon cas, je n'avais pas réalisé que le paquet AspNetCore manquait et devait être installé! Si heureux j'ai trouvé ce post !!
Cela peut être lié ou non ... J'ai commencé avec la même erreur que celle mentionnée ci-dessus, j'ai commencé à googler, à apporter des modifications, à obtenir de nouvelles erreurs, à une boucle sans fin.
Le changement qui m'a causé par cette erreur a été gâché avec la délégation de fonctionnalités dans IIS Manager dans la section Gestion du serveur. Je suis désolé, je ne me souviens pas lequel j'ai changé, mais googler pourrait aider.
Cela m'a permis de passer la première erreur à un tout nouveau flux d'autres, certains totalement insensés. (J'obtiendrais une erreur lors de l'exécution sous un répertoire virtuel, le convertir en une application produirait une autre erreur, etec, etc.). Ce qui a finalement résolu cette série d’erreurs est le suivant: IIS gestionnaire, pools d’applications, DefaultAppPool, activer les applications 32 bits = True
J'avais démarré cette application sur une boîte Windows XP 32 bits et je l'exécute maintenant sur une boîte Windows 7 64 bits.
Donc, espérons que cela aide quelqu'un d'autre.
J'ai eu cette erreur en plaçant la balise <customErrors> à l'intérieur de <system.webServer> au lieu de <system.web> à laquelle elle appartient. Il y avait un petit gribouillage sous la balise <customErrors> mais je ne l'ai pas remarquée tout de suite.
Windows 7
Essaye ça,
lancez cmd en tant qu'administrateur.
Unistall tous les iis.
start /w pkgmgr.exe /uu:IIS-WebServerRole;WAS-WindowsActivationService
Réinstallez iis et c'est normalement son travail
Alain
Assurez-vous que toutes vos fonctionnalités IIS sont correctement activées.
- Ouvrir Fonctionnalités Windows (activer ou désactiver les fonctionnalités Windows).
Faites défiler jusqu'à Internet Information Services
Ouvrez le menu déroulant World Wide Web plus
- Ouvrez la liste déroulante Fonctions de développement d’application et
- Cochez manuellement toutes les cases suivantes, puis cliquez sur ok
J'ai eu le même problème dans Windows 7.
La solution consistait à accéder aux paramètres de base> se connecter en tant que> utilisateur spécifique - et de se connecter en tant qu'utilisateur, au lieu de la "transmission directe" par défaut.
Cela a résolu le problème pour moi.