Un paramètre ASP.NET a été détecté qui ne s'applique pas en mode de pipeline géré intégré

J'ai installé DotNetOpenAuth SDK-3.4.5.10201.vsix et je ne peux pas le faire fonctionner. Cela fonctionne localement (lorsque je cours en tant qu'hôte local), mais lorsque j'essaie de le publier, cela ne fonctionne pas.

Le message d'erreur IIS que j'obtiens est

Résumé de l'erreur Erreur
HTTP 500.22 - Erreur de serveur interne
Un paramètre ASP.NET a été détecté qui ne s'applique pas en mode de pipeline géré intégré.

ET

Module       ConfigurationValidationModule  
Notification BeginRequest  
Handler      StaticFile  
Error Code   0x80070032  

puis il y a quelques suggestions sur la façon de résoudre le problème:

Choses que vous pouvez essayer:

• Migrez la configuration vers la system.webServer/modulessection. Vous pouvez le faire manuellement ou en utilisant APPCMD de la ligne de commande - par exemple %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/". L'utilisation AppCmdde la migration de votre application lui permettra de fonctionner en mode intégré et de continuer à fonctionner en mode classique et sur les versions précédentes d'IIS.

• Si vous êtes certain qu'il est OK d'ignorer cette erreur, elle peut être désactivée en définissant la valeur system.webServer/validation@validateIntegratedModeConfiguration false.

• Vous pouvez également basculer l'application vers un pool d'applications en mode classique, par exemple %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool",. Ne faites cela que si vous ne parvenez pas à migrer votre application.
  (Définissez "Site Web par défaut" et "Classic .NET AppPool" sur le chemin de votre application et le nom du pool d'applications)

Mais le problème est que je n'ai pas accès au serveur ISS car je n'en suis pas propriétaire. Est-ce qu'il y a un moyen de résoudre ceci?

La 2 ^e option est celle que vous souhaitez.

Dans votre web.config, assurez-vous que ces clés existent:

<configuration>
    <system.webServer>
        <validation validateIntegratedModeConfiguration="false"/>
    </system.webServer>
</configuration>

L'ajout <validation validateIntegratedModeConfiguration="false"/>résout le problème, mais n'est pas approprié dans toutes les circonstances. Ayant contourné ce problème plusieurs fois, j'espère aider les autres non seulement à surmonter le problème mais aussi à le comprendre. (Ce qui devient de plus en plus important à mesure qu'IIS 6 disparaît dans le mythe et la rumeur.)

Contexte:

Ce problème et la confusion qui l'entoure ont commencé avec l'introduction d'ASP.NET 2.0 et IIS 7. IIS 6 n'avait et continue d'avoir qu'un seul mode de pipeline, et il est équivalent à ce que IIS 7+ appelle le mode "Classic". Le second mode de pipeline, plus récent et recommandé pour toutes les applications exécutées sur IIS 7+, est appelé mode «intégré».

Alors, quelle est la différence? La principale différence réside dans la façon dont ASP.NET interagit avec IIS.

• Mode classiqueest limité à un pipeline ASP.NET qui ne peut pas interagir avec le pipeline IIS. Essentiellement, une demande arrive et si IIS 6 / Classic a été informé, par le biais de la configuration du serveur, qu'ASP.NET peut la gérer, puis IIS transfère la demande à ASP.NET et passe à autre chose. L'importance de cela peut être glanée à partir d'un exemple. Si je devais autoriser l'accès aux fichiers d'images statiques, je ne serais pas en mesure de le faire avec un module ASP.NET car le pipeline IIS 6 traitera ces demandes lui-même et ASP.NET ne verra jamais ces demandes car elles n'ont jamais été transmises . * D'un autre côté, autoriser les utilisateurs qui peuvent accéder à une page .ASPX telle qu'une demande pour Foo.aspx est trivial même dans IIS 6 / Classic car IIS transmet toujours ces demandes au pipeline ASP.NET. En mode classique, ASP.NET ne sait pas ce qu'il n'a pas

• Le mode intégré est recommandé car les gestionnaires et modules ASP.NET peuvent interagir directement avec le pipeline IIS. Le pipeline IIS ne transfère plus simplement la demande au pipeline ASP.NET, il permet désormais au code ASP.NET de se connecter directement au pipeline IIS et à toutes les demandes qui l'ont atteint. Cela signifie qu'un module ASP.NET peut non seulement observer les demandes de fichiers d'images statiques, mais peut intercepter ces demandes et prendre des mesures en refusant l'accès, en enregistrant la demande, etc.

Surmonter l'erreur:

1. Si vous exécutez une ancienne application créée à l'origine pour IIS 6, peut-être que vous l'avez déplacée vers un nouveau serveur, il ne peut y avoir absolument rien de mal à exécuter le pool d'applications de cette application en mode classique. Allez-y, vous n'avez pas à vous sentir mal.

2. Là encore, peut-être que vous donnez un coup de jeune à votre application ou qu'elle progressait très bien jusqu'à ce que vous installiez une bibliothèque tierce via NuGet, manuellement ou par un autre moyen. Dans ce cas, il est tout à fait possible httpHandlersou httpModulesa été ajouté à system.web. Le résultat est l'erreur que vous voyez en raison des validateIntegratedModeConfigurationvaleurs par défaut true. Vous avez maintenant deux choix:

   1. Supprimez les éléments httpHandlerset . Il y a quelques résultats possibles à cela: httpModulessystem.web
      • Tout fonctionne bien, un résultat commun;
      • Votre application continue de se plaindre, il peut y avoir un web.config dans un dossier parent dont vous héritez, pensez également à nettoyer ce web.config;
      • Vous en avez assez de supprimer le httpHandlerset httpModulesque les packages NuGet continuent d'ajouter system.web, hé faites ce dont vous avez besoin.
3. Si ces options ne fonctionnent pas ou sont plus d' ennuis que cela vaut la peine alors je ne vais pas vous dire que vous ne pouvez pas mettre validateIntegratedModeConfigurationà false, mais au moins vous savez ce que vous faites et pourquoi il est important.

Bonnes lectures:

• ASP.NET 2.0 Breaking Changes sur IIS 7.0
• Intégration ASP.NET avec IIS 7
• Présentation des gestionnaires HTTP et des modules HTTP

* Bien sûr, il existe des moyens d'intégrer toutes sortes de choses étranges dans le pipeline ASP.NET à partir d'IIS 6 / Classic via des incantations comme des mappages génériques , si vous aimez ce genre de chose.

Si vous devez toujours utiliser le module HTTP, vous devez le configurer (framework .NET 4.0) comme suit:

<system.webServer>
   <modules runAllManagedModulesForAllRequests="true">
       <add name="MyModule" type="[Namespace].[Class], [assembly]"/>
   </modules>
   <validation validateIntegratedModeConfiguration="false"/>
</system.webServer>

J'ai rencontré ce problème mais j'ai eu un correctif différent. Cela impliquait la mise à jour Control Panel>Administrative Tools>IIS Manageret la restauration du pipeline géré de mon site d'application de Integratedà Classic.

Vérifiez s'il y a un conflit dans votre authentification IIS. c'est-à-dire que vous activez l'authentification anonyme et l'emprunt d'identité ASP.NET, les deux peuvent également provoquer l'erreur.

Dans votre web.config assurez-vous que ces clés existent:

<configuration>
    <system.webServer>
        <validation validateIntegratedModeConfiguration="false"/>
    </system.webServer>
</configuration>

En plus de vérifier le impresonation Asp.Net = désactiver dans l'authentification du site IIS

J'ai rencontré ce problème et inspiré par la réponse de @Jeremy Cook, j'ai mordu la balle pour savoir ce qui a fait que le mode intégré IIS 7 n'aimait pas mon web.config. Voici mon scénario:

1. API Web (version 4.0.030506.0 alias l'ancienne)
2. .NET 4.0
3. Routage d'attributs 3.5.6 pour l'API Web [alerte spoiler: c'était ce type!]

Je voulais utiliser le routage d'attributs dans un projet qui (malheureusement) devait utiliser .NET 4 et ne pouvait donc pas utiliser Web API 2.2 (qui a besoin de .NET 4.5). Le package NuGet bien intentionné a ajouté cette section sous la <system.web>section:

<system.web>
<httpHandlers>
      <add verb="*" path="routes.axd" type="AttributeRouting.Web.Logging.LogRoutesHandler, AttributeRouting.Web" />
    </httpHandlers>
</system.web>

[Je dis bien intentionné, car cette partie est requise sur les anciennes versions d'IIS]

La suppression de cette section m'a permis de dépasser le HTTP 500.23 !!

Résumé: J'appuie les mots de Jeremy qu'il est important de comprendre pourquoi les choses ne fonctionnent pas plutôt que de simplement "masquer le symptôme". Même si vous devez masquer le symptôme, vous savez ce que vous faites (et pourquoi) :-)

Cela a fonctionné pour moi:

1. Supprimez le site créé à l'origine.
2. Recréer le site dans IIS
3. Solution propre
4. Créer une solution

On dirait que quelque chose est allé au sud lorsque j'ai créé le site à l'origine. Je déteste les solutions similaires à «Redémarrez votre ordinateur, puis réinstallez Windows» sans savoir ce qui a causé l'erreur. Mais cela a fonctionné pour moi. Rapide et simple. J'espère que cela aide quelqu'un d'autre.

Dans mon cas, il me manquait la DLL dans le dossier bin qui était référencé dans le fichier web.config. Vérifiez donc si vous utilisiez un paramètre dans web.config mais que vous n'avez pas de dll.

Merci

Cela m'a pris quelques heures pour résoudre ce problème car tous les paramètres que j'ai trouvés ici à propos de cette erreur étaient les mêmes, mais cela ne fonctionnait toujours pas. Le problème était que j'avais un dossier dans mon service Web à partir duquel le fichier devait être envoyé au périphérique WinCE, après avoir converti ce dossier en une application avec Classic.NetAppPool, il a commencé à fonctionner.

L'étape ci-dessous a résolu mon problème:

Ouvrez l' CMDinvite avec les privilèges d'administrateur.

Courir : iisreset.

J'espère que cela t'aides.

La méthode pour local est l'erreur