web-dev-qa-db-fra.com

Un paramètre ASP.NET 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 parviens pas à le faire fonctionner… .. Il fonctionne localement (quand je suis localhost) mais j'essaie de le publier mais il ne fonctionne pas. 

Le message d'erreur IIS que je reçois est 

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

ET

Module       ConfigurationValidationModule  
Notification BeginRequest  
Handler      StaticFile  
Error Code   0x80070032

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

Choses que vous pouvez essayer:

  • Migrer la configuration vers le system.webServer/modules section. Vous peut le faire manuellement ou en utilisant AppCmd ​​ à partir de la ligne de commande - par exemple, %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/". Utilisez AppCmd pour migrer votre L’application lui permettra de fonctionner en Mode intégré et continuer à travailler en mode classique et sur précédent versions de IIS.

  • Si vous êtes certain que cela vous convient. ignorer cette erreur, elle peut être désactivée par réglage system.webServer/validation@validateIntegratedModeConfiguration à faux. 

  • Sinon, changez d’application dans 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 êtes impossible de 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 le propriétaire. Est-ce qu'il y a un moyen de résoudre ceci?

c#asp.netiis.net-4.0iis-7.5
372
Mikael

Les deuxdakota du Nord l'option est celle que vous voulez.

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

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

L'ajout de <validation validateIntegratedModeConfiguration="false"/> répond au symptôme, mais ne convient pas à toutes les circonstances. Ayant couru plusieurs fois autour de cette question, j'espère pouvoir aider les autres non seulement à surmonter le problème, mais également à le comprendre. (Ce qui devient de plus en plus important à mesure que IIS 6 disparaît dans le mythe et la rumeur.)

Contexte:

Ce problème et la confusion qui l’entourait ont commencé avec l’introduction d’ASP.NET 2.0 et de IIS 7. IIS 6 n’avait et n’avait toujours qu’un mode de pipeline, ce qui est équivalent à ce que IIS 7+ appels en mode "classique". Le deuxième 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 manière dont ASP.NET interagit avec IIS.

  • Le mode Classic est 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é, via la configuration du serveur, qu'ASP.NET peut la gérer, IIS transmet ensuite la demande à ASP.NET et passe à autre chose. La signification de ceci peut être tirée d'un exemple. Si je devais autoriser l'accès aux fichiers images statiques, je ne serais pas en mesure de le faire avec un module ASP.NET car le pipeline IIS 6 gérera ces demandes lui-même et ASP.NET ne les verra jamais car elles n'a jamais été transféré. * D'autre part, autoriser les utilisateurs à accéder à une page .ASPX, telle qu'une requête pour Foo.aspx, est trivial même dans IIS 6/Classic, car IIS transmet toujours ces requêtes. hors du pipeline ASP.NET. En mode classique, ASP.NET ne sait pas ce qui n'a pas été dit et il y a beaucoup de choses que IIS 6/Classic pourrait ne pas dire.

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

Surmonter l'erreur:

  1. Si vous exécutez une application plus ancienne construite à l'origine pour IIS 6, vous l'avez peut-être déplacée vers un nouveau serveur, l'exécution du pool d'applications de cette application en mode classique est tout à fait irréprochable. Allez-y, vous n'avez pas à vous sentir mal.

  2. Là encore, vous appliquez peut-être un lifting à votre application ou vous vous en êtes bien servie jusqu'à ce que vous ayez installé une bibliothèque tierce partie via NuGet, manuellement ou par un autre moyen. Dans ce cas, il est tout à fait possible que httpHandlers ou httpModules ait été ajouté à system.web. Le résultat est l'erreur que vous voyez parce que validateIntegratedModeConfiguration est défini par défaut true. Maintenant vous avez deux choix:

    1. Supprimez les éléments httpHandlers et httpModules de system.web. Il en résulte deux résultats possibles:
      • Tout fonctionne bien, un résultat commun;
      • Votre application continue à se plaindre, il se peut qu'il y ait un fichier web.config dans un dossier parent dont vous héritez. Pensez également à nettoyer ce fichier Web.config;
      • Vous en avez assez de supprimer les variables httpHandlers et httpModules que les packages NuGet ne cessent d’ajouter à system.web, mais faites ce que vous avez à faire.
  3. Si ces options ne fonctionnent pas ou ne posent pas plus de problèmes, je ne vais pas vous dire que vous ne pouvez pas régler validateIntegratedModeConfiguration sur false, mais au moins vous savez ce que vous faites et pourquoi c'est important.

Bonne lecture:

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

101
Jeremy Cook

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

<system.webServer>
   <modules runAllManagedModulesForAllRequests="true">
       <add name="MyModule" type="[Namespace].[Class], [Assembly]"/>
   </modules>
   <validation validateIntegratedModeConfiguration="false"/>
</system.webServer>
34
Ashraf Sayied-Ahmad

J'ai rencontré ce problème, mais j'avais un correctif différent. Il s'agissait de mettre à jour le Control Panel>Administrative Tools>IIS Manager et de rétablir le pipeline géré de mon site d'application de Integrated à Classic.

31
Gaʀʀʏ

Vérifiez s'il y a un conflit dans votre authentification IIS. Autrement dit, vous activez l'authentification anonyme et l'emprunt d'identité ASP.NET peuvent également causer l'erreur.

7
Jim Yu

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 l’impression de site Asp.Net = Disable In IIS 

3
Nil

Cela a fonctionné pour moi:

  1. Supprimer le site créé à l'origine.
  2. Recréer le site dans IIS
  3. Solution propre
  4. Construire la solution

On dirait que quelque chose est allé au sud quand j'ai créé le site à l'origine. Je déteste les solutions similaires à "Redémarrez votre ordinateur, puis réinstallez Windows" sans savoir la cause de l'erreur. Mais cela a fonctionné pour moi. Simple et rapide J'espère que ça aide quelqu'un d'autre.

2
Paul

Je me suis heurté à ce problème et, inspiré par la réponse de @Jeremy Cook, j'ai mordu la balle pour découvrir ce qui a causé le fait que IIS 7 Integrated Mode ne ressemble pas à mon web.config. Voici mon scénario:

  1. API Web (version 4.0.030506.0 aussi appelée l'ancienne)
  2. .NET 4.0
  3. Attribute Routing 3.5.6 for Web API [alerte spoiler: c'était ce gars-là!]

Je souhaitais 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 nécessite .NET 4.5). Le paquetage bien intentionné NuGet a ajouté cette section sous la section <system.web>:

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

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

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

Résumé: Je partage les paroles de Jeremy selon lesquelles il est important de comprendre pourquoi les choses ne fonctionnent pas plutôt que de "masquer le symptôme". Même si vous devez masquer le symptôme, vous savez ce que vous faites (et pourquoi) :-)

1
Sudhanshu Mishra

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 qu’il y avait un dossier dans mon service Web à partir duquel le fichier devait être envoyé au périphérique WinCE. Après la conversion de ce dossier en une application avec Classic.NetAppPool, il a commencé à fonctionner.

0
Mladen Radosović

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

Merci

0
naveen rawat