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 y avoir une partie simple mal configurée d'IIS ou de notre serveur Web, mais chaque fois que nous essayons d'exécuter l'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 exécute Windows Server 2008 R2 . Nous développons notre application Web à l'aide de Visual Studio 2008 .

Selon Microsoft, le code 8007000d signifie qu'il y a une erreur de syntaxe dans notre web.config - sauf que le projet se construit et s'exécute correctement localement. Regarder le web.config dans le bloc-notes XML ne soulève pas non plus d'erreurs de syntaxe. Je suppose que cela doit être une sorte de mauvaise configuration de ma part ...?

Quelqu'un sait-il où je pourrais trouver des informations supplémentaires sur l'erreur? Rien ne s'affiche dans EventViewer, non plus :(

Je ne sais pas quoi d'autre serait utile de mentionner ...

L'aide est grandement appréciée. Merci!

MISES À JOUR! - WEB.CONFIG PUBLIÉ CI-DESSOUS

Ok, depuis que j'ai posté la question originale ci-dessus, j'ai retracé les lignes précises dans le web.config qui étaient à l'origine de l'erreur.

Voici les lignes (elles apparaissent entre les <System.webServer>balises) ...

    <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 le, <httpHandlers>j'obtiens TOUJOURS l'erreur. Je dois littéralement supprimer <httpHandlers>(et les lignes intermédiaires) pour arrêter d'obtenir l'erreur ci-dessus.

Une fois que j'ai fait cela, j'obtiens une nouvelle erreur 500.19, cependant. Heureusement, cette fois, IIS me dit quelle partie du fichier web.config pose 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é plus loin dans la même <system.webServer>balise vers la <handlers>balise.

La nouvelle erreur est également plus explicite et se plaint spécifiquement de ne pas reconnaître l'attribut «valider» (comme vu sur la troisième ligne ci-dessus). La suppression de cet attribut fait alors se plaindre que la même ligne n'a pas l'attribut "nom" requis. L'ajout de cet attribut fait apparaître une erreur ASP.NET ...

Impossible de charger le fichier ou l'assembly 'System.web.Extensions, Version = 1.0.61025.0, Culture = neutral, PublicKeyToken = f2cb5667dc123a56' ou l'une de ses dépendances. Le système ne peut pas trouver le fichier spécifié.

De toute évidence, je pense que ces nouvelles erreurs viennent de ma suppression des <httpHandlers>balises en premier lieu - elles sont évidemment nécessaires à l'application - donc la question demeure: pourquoi ces balises déclencheraient-elles une erreur dans IIS en premier lieu? ??

Dois-je installer quelque chose sur IIS pour qu'il fonctionne avec eux?

Merci encore pour toute aide.

WEB.CONFIG

Voici les éléments gênants de notre web.Config ... J'espère que cela aidera 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>

J'avais ces symptômes exacts et mon problème était similaire à 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 qui n'avait pas encore été installé sur le nouveau serveur. L'installer a résolu mon problème.

Vous pouvez utiliser le programme d'installation de Microsoft Web Platform pour l'installer. Exécutez-le, sélectionnez Produits , dans le menu de gauche, sélectionnez Serveur et recherchez Réécriture d'URL dans la liste et installez-la.

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 réglé.

http://forums.iis.net/t/1176834.aspx

http://learn.iis.net/page.aspx/460/using-the-url-rewrite-module/

Ah! J'ai battu ce problème! Mon dieu, c'était une bête pour quelqu'un comme moi avec une expérience IIS limitée. Je pensais vraiment que j'allais passer tout le week-end à le réparer.

Voici la solution pour quiconque se heurte à ce problème pervers.

Première chose à savoir: si vous espérez que c'est votre solution, assurez-vous que vous avez le même code d'erreur ( 0x8007000d ) et la même source de configuration ( -1: 0 :) . Sinon, ce n'est pas votre solution.

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 tout!

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 web.config d'IIS 7 fonctionnera, ou est conçu pour fonctionner, mais l'absence de ce module donne une erreur vraiment étrange et inutile. Googler vous amène à une page Microsoft qui insiste sur le fait que votre site est corrompu ou que votre web.config est corrompu. Ni l'un ni l'autre ne semble être le cas.

Cette page inutile est ici: https://support.microsoft.com/en-us/kb/942055

J'ai eu le même problème que ci-dessus, le même code d'erreur, etc. Configuration d'un site Web local sur Windows 8. Après de nombreuses recherches, il a été constaté que nous manquions de réécriture d'URL. Après l'avoir téléchargé, tout allait bien. :)

J'ajoute simplement un vêtement 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:

1. Vérifiez la version .NET du pool d'applications (par exemple, 2.0 vs 4.0)
2. Vérifiez que tous les modules référencés IIS sont installés. Dans ce cas, il s'agissait des extensions AJAX (probablement pas le cas de nos jours), mais la réécriture d'URL est courante.

Une autre façon d'obtenir l'erreur 500.19 sans raison apparente est - des répertoires manquants et / ou des autorisations brisées sur eux.

Dans le cas de cette question, je crois que la question concerne la version complète d'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 wwwrootpour vous et c'est le dossier racine par défaut pour tous les sites Web et le point de montage pour les répertoires virtuels. Cela existe toujours, donc pas de problème, vous ne vous souciez généralement pas beaucoup de cela.

Étant donné que les fichiers web.config sont hiérarchiques, vous pouvez y placer un fichier maître web.config et y avoir des paramètres racine, et tous les sites en hériteront. IIS vérifie si ce fichier existe et tente de le charger.

Cependant, première partie amusante:

Ce répertoire existe si IIS est correctement installé. S'il n'existe pas, vous obtiendrez une erreur de classe 500. Cependant, si vous jouez avec des autorisations de fichier / répertoire, en particulier des autorisations `` avancées '', vous pouvez en fait refuser accidentellement au compte de service IIS de scanner / lire le contenu de ce répertoire. Si IIS est incapable de vérifier si ce wwwroot \ web.config existe, ou s'il existe et que IIS ne peut pas l'ouvrir et le lire - erreur de classe 500 bam.

Cependant, pour IIS complet, il est très peu probable. Les développeurs / administrateurs travaillant avec IIS complet sont généralement réticents à jouer avec, wwwrootdonc il reste généralement correctement configuré.

Cependant, sur IIS Express.

Habituellement, IIS Express "fonctionne simplement". Souvent, les développeurs utilisant IIS Express ne savent souvent pas à quel point il ressemble en interne au véritable IIS.

Vous pouvez facilement tomber sur le fait qu'IIS Express a son propre fichier applicationHost.config et VS le crée et le gère pour vous (correctement, dans une certaine mesure) et ce genre de révélateur vous dit que ce n'est pas si simple et précis. et cliquez comme il semble au premier abord.

En plus de ce fichier de configuration, VisualStudio crée également une structure de répertoires vide sous votre Documentsdossier. Si je me souviens bien, IIS Express considère ces dossiers comme les répertoires racine de vos sites Web sur lesquels sont montés les répertoires virtuels avec votre code.

Plus tard, tout comme IIS, lorsque IIS Express démarre, il s'attend à ce que ces dossiers existent et y recherche les fichiers racine web.config. Les fichiers web.config du site . Presque toujours, ces fichiers web.config manquent - et ce n'est pas grave car vous ne les voulez pas - vous avez votre ** application web.config ", ils sont placés avec le reste du contenu dans un répertoire virtuel.

Maintenant, la deuxième partie amusante est: IIS Express s'attend à ce que les répertoires vides. Ils peuvent être vides, mais ils doivent exister. S'ils n'existent pas - vous obtiendrez une erreur de classe 500 vous indiquant que le fichier "web.config" sur ce chemin n'est pas accessible.

La première fois que j'ai rencontré ce problème, c'était lorsque j'effaçais mon disque dur. J'ai trouvé que le dossier «documents \ sites», plein de poubelles, j'ai reconnu des projets vieux de plusieurs années sur lesquels je ne travaille plus, tous vides, pas un seul fichier, donc j'ai tout supprimé. Une semaine plus tard - bam - je ne peux exécuter / déboguer aucun des sites sur lesquels je travaillais en ce moment. L'erreur était 500.19, impossible de lire le fichier de configuration.

Donc, si vous utilisez IIS Express et voyez une erreur de classe 500 indiquant 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 là où l'erreur l'indique, assurez-vous que ces dossiers existent, assurez-vous que le compte de travail IIS peut les parcourir et les lire, et si vous remarquez que quelque chose ne va pas, ce sera peut-être le cas.

BTW. Dans VisualStudio, sur ProjectProperties / Web, il y a un bouton "Créer un répertoire virtuel". Il fait essentiellement cette chose, vous pouvez donc l'essayer d'abord, mais IIRC peut aussi parfois effacer / écraser / échanger des sections de configuration dans le fichier applicationHost.config, alors soyez prudent avec ce bouton si vous avez des configurations personnalisées.

Dans mon cas, il y avait un problème avec l'installation du bundle d'hébergement Windows .NET Core.

Je l'avais installé et j'avais redémarré IIS en utilisant ("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 bundle d'hébergement Windows .NET Core et en redémarrant IIS à l'aide des commandes mentionnées ci-dessus.

J'espère que cela aide quelqu'un!

Cette belle erreur détaillée est toujours présente en 2019! Je veux juste ajouter que si votre web.configest valide et accessible, il s'agit probablement d'un problème de dépendance .

Comme mentionné par l'OP, il s'agissait d'un AJAXmodule, et comme par d'autres généralement le Rewritemodule. Gardez simplement les yeux ouverts dans votre web.config sur les modules et bibliothèques auxquels vos balises font référence, car le code d'erreur 0x8007000d peut concerner N'IMPORTE QUELLE dépendance .

Dans mon cas, je n'avais pas réalisé que le AspNetCorebundle manquait et devait être installé! Tellement heureux d'avoir trouvé ce post !!

Cela peut être lié ou non .... J'ai commencé avec la même erreur mentionnée ci-dessus, j'ai commencé à rechercher sur Google, à apporter des modifications, à obtenir de nouvelles erreurs, à une boucle sans fin.

Le changement qui m'a attiré par cette erreur perturbait la délégation de fonctionnalités dans le gestionnaire IIS sous la section Gestion du serveur. Je suis désolé, je ne me souviens plus lequel j'ai changé, mais googler pourrait aider.

Cela m'a fait passer la première erreur dans un tout nouveau flux d'autres, certains totalement absurdes. (J'obtiendrais une erreur lors de l'exécution sous un répertoire virtuel, la conversion en une application produisait une autre erreur, etc.). Ce qui a finalement résolu cette série d'erreurs était: IIS manager, Application Pools, DefaultAppPool, Enable 32-Bit applications = 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.

J'espère que cela aidera quelqu'un d'autre.

Mon IIS 7.5 ne comprend pas la balise dans web.config Dans VS 2010, il est également souligné cette balise. Vérifiez que votre fichier de configuration est précis pour trouver toutes les balises soulignées. Je l'ai mis dans le commentaire et l'erreur disparaît.

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.

J'ai eu la même erreur. J'avais un site IIS avec .net framework version 2.0, mais mon application avait besoin de 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.

Assurez-vous que toutes vos fonctionnalités IIS sont correctement activées.

• Ouvrez les fonctionnalités Windows (activez ou désactivez les fonctionnalités Windows).

• Faites défiler jusqu'à Internet Information Services

• Ouvrez la liste déroulante World Wide Web plus

• Ouvrez la liste déroulante Fonctionnalités de développement d'applications plus
• Cochez manuellement toutes les cases à cocher suivantes, puis cliquez sur OK

La configuration ci-dessous était la cause de mon problème:

    <rewrite>
      <rules>
        <clear />
        <rule name="Redirect to HTTPS" stopProcessing="true">
          <match url="(.*)" />
          <conditions>
            <add input="{HTTP_HOST}" pattern="^.*spvitals\.com$" />
            <add input="{HTTPS}" pattern="off" ignoreCase="true" />
          </conditions>
          <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Permanent" appendQueryString="false" />
        </rule>
      </rules>
    </rewrite>

Remarque: j'ai supprimé cette section pour les tests locaux, car elle fonctionne correctement dans Azure.

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 à se connecter en tant qu'utilisateur, au lieu du 'pass-through' par défaut

Cela a résolu le problème pour moi.

Windows 7

Essaye ça,

exécutez cmd en tant qu'administrateur.

Désinstaller tous les iis.

start /w pkgmgr.exe /uu:IIS-WebServerRole;WAS-WindowsActivationService

Réinstaller iis et normalement ça marche

Alain

J'ai eu cette erreur en mettant la <customErrors>balise à l'intérieur de <system.webServer>au lieu de son <system.web>emplacement. Il y avait un petit gribouillage sous l' <customErrors>étiquette mais je ne l'ai pas remarqué tout de suite.

Semblable à la première réponse , nous recevions cette exception incroyablement inutile en raison d'un module IIS CORS manquant. C'était exactement la même erreur avec le code d'erreur (0x8007000d) et la source de configuration (-1: 0 :), mais l'installation du module de réécriture d'URL ne l'a pas corrigée.

Nous avions récemment mis à jour le fichier web.config pour activer CORS pour certains développeurs qui en avaient besoin, mais nous ne nous attendions pas à ce qu'il soit nécessaire pour tous les développeurs d'installer le module IIS CORS. Malheureusement, cela semble nécessaire.

Pour résoudre ce problème, installez le module IIS CORS à partir d'ici .

Si vous déployez l'application asp.net.core, vous devez également installer le bundle d'hébergement principal .net. https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/index?view=aspnetcore-3.0#install-the-net-core-hosting-bundle