Se ha detectado una configuración de ASP.NET que no se aplica en el modo de canalización administrado integrado


401

Instalé DotNetOpenAuth SDK-3.4.5.10201.vsix y no puedo hacerlo funcionar. Funciona localmente (cuando ejecuto como localhost) pero cuando intento publicarlo no funciona.

El mensaje de error de IIS que recibo es

Resumen de error Error
HTTP 500.22 - Error interno del servidor
Se ha detectado una configuración ASP.NET que no se aplica en el modo de canalización administrada integrada.

Y

Module       ConfigurationValidationModule  
Notification BeginRequest  
Handler      StaticFile  
Error Code   0x80070032  

entonces hay algunas sugerencias sobre cómo resolver el problema:

Cosas que puedes probar:

  • Migre la configuración a la system.webServer/modulessección. Puede hacerlo de forma manual o mediante el uso de appcmd desde la línea de comandos - por ejemplo, %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/". El uso AppCmdpara migrar su aplicación le permitirá funcionar en modo Integrado y continuar trabajando en modo Clásico y en versiones anteriores de IIS.

  • Si está seguro de que está bien ignorar este error, se puede deshabilitar estableciendo system.webServer/validation@validateIntegratedModeConfiguration en falso.

  • Alternativamente, cambie la aplicación a un grupo de aplicaciones en modo clásico, por ejemplo %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool",. Solo haga esto si no puede migrar su aplicación.
    (Establezca "Sitio web predeterminado" y "Grupo de aplicaciones .NET clásico" en la ruta de la aplicación y el nombre del grupo de aplicaciones)

Pero el problema es que no tengo acceso al servidor ISS ya que no soy el propietario del mismo. ¿Hay alguna forma de resolver esto?

Respuestas:


782

El 2do opción es la que deseas.

En su web.config, asegúrese de que existan estas claves:

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

10
Esto realmente no debería afectar la seguridad de su aplicación. Simplemente apaga la advertencia que dice que tiene algunos valores de configuración que no se utilizarán.
David

19
Esto no es realmente un consejo excesivamente sólido si tiene configuraciones que no se utilizarán, entonces debe eliminarlas.
Seph

33
@Seph, no estoy de acuerdo con que esto no sea un buen consejo. Muchas instalaciones de NuGet (por ejemplo, DotLess) agregarán entradas a las secciones que se aplican al modo integrado, y también duplicarán esa configuración para el modo no integrado. Esto se llama portabilidad y permite que su configuración funcione independientemente de si está utilizando IIS7 / integrado o clásico. La única razón para dejar esta configuración de validación truees para que pueda dejar sus ruedas de entrenamiento encendidas y que IIS le grite cada vez que agregue una configuración que no funcionará en modo integrado. Esto es para los inexpertos, pero se interpone en el camino.
Kirk Woll

55
Este tipo de configuración es molesto. @MS: hay una mejor manera.
yonexbat

3
Para aquellos que prefieren corregir los errores antes que enmascarar los síntomas, publiqué una respuesta alternativa. Con respecto a los paquetes NuGet, ¿por qué seguimos apuntando a IIS 6 / Classic?
Jeremy Cook

104

Agregar <validation validateIntegratedModeConfiguration="false"/>aborda el síntoma, pero no es apropiado para todas las circunstancias. Habiendo solucionado este problema varias veces, espero ayudar a otros no solo a superar el problema, sino también a comprenderlo. (Lo que se vuelve cada vez más importante a medida que IIS 6 se desvanece en mitos y rumores).

Antecedentes:

Este problema y la confusión que lo rodea comenzaron con la introducción de ASP.NET 2.0 e IIS 7. IIS 6 tenía y sigue teniendo solo un modo de canalización, y es equivalente a lo que IIS 7+ llama modo "Clásico". El segundo modo de canalización más nuevo y recomendado para todas las aplicaciones que se ejecutan en IIS 7+ se llama modo "Integrado".

Entonces, ¿cuál es la diferencia? La diferencia clave es cómo ASP.NET interactúa con IIS.

  • Modo clásicoestá limitado a una tubería ASP.NET que no puede interactuar con la tubería IIS. Esencialmente, entra una solicitud y si a IIS 6 / Classic se le ha dicho, a través de la configuración del servidor, que ASP.NET puede manejarlo, entonces IIS transfiere la solicitud a ASP.NET y continúa. La importancia de esto se puede deducir de un ejemplo. Si tuviera que autorizar el acceso a archivos de imágenes estáticas, no podría hacerlo con un módulo ASP.NET porque la canalización de IIS 6 manejará esas solicitudes y ASP.NET nunca verá esas solicitudes porque nunca se entregaron . * Por otro lado, autorizar qué usuarios pueden acceder a una página .ASPX como una solicitud de Foo.aspx es trivial incluso en IIS 6 / Classic porque IIS siempre entrega esas solicitudes a la canalización de ASP.NET. En modo clásico, ASP.NET no sabe lo que no tiene

  • Se recomienda el modo integrado porque los controladores y módulos ASP.NET pueden interactuar directamente con la tubería IIS. La canalización de IIS ya no entrega la solicitud a la canalización de ASP.NET, ahora permite que el código de ASP.NET se enganche directamente en la canalización de IIS y todas las solicitudes que lo afectan. Esto significa que un módulo ASP.NET no solo puede observar solicitudes a archivos de imágenes estáticas, sino que puede interceptar esas solicitudes y tomar medidas al denegar el acceso, registrar la solicitud, etc.

Superar el error:

  1. Si está ejecutando una aplicación anterior que se creó originalmente para IIS 6, quizás la haya movido a un nuevo servidor, puede que no haya absolutamente nada de malo en ejecutar el grupo de aplicaciones de esa aplicación en modo clásico. Adelante, no tienes que sentirte mal.
  2. Por otra parte, tal vez le esté dando a su aplicación una cirugía estética o estaba funcionando muy bien hasta que instaló una biblioteca de terceros a través de NuGet, manualmente o por algún otro medio. En ese caso, es totalmente posible httpHandlerso httpModulesse ha agregado a system.web. El resultado es el error que está viendo porque está validateIntegratedModeConfigurationpredeterminado true. Ahora tienes dos opciones:

    1. Eliminar los elementos httpHandlersy httpModulesde system.web. Hay un par de posibles resultados de esto:
      • Todo funciona bien, un resultado común;
      • Su aplicación continúa quejándose, puede haber un web.config en una carpeta principal de la que está heredando, considere limpiar ese web.config también;
      • Te cansas de eliminar httpHandlersy los httpModulespaquetes NuGet siguen agregando system.web, oye, haz lo que necesites.
  3. Si estas opciones no funcionan o son más problemas de lo que vale entonces yo no voy a decir que no se puede establecer validateIntegratedModeConfigurationa false, pero por lo menos saben lo que está haciendo y por qué es importante.

Buenas lecturas:

* Por supuesto, hay formas de introducir todo tipo de cosas extrañas en la canalización de ASP.NET desde IIS 6 / Classic a través de encantamientos como asignaciones de comodines , si te gusta ese tipo de cosas.


La única solución +1 no es una respuesta a su problema, sino una solución con una explicación que es la respuesta perfecta. Qué es y por qué necesitamos cambiar esto, estas preguntas de respuesta dadas por @Jeremy cook answer.
Rikin Patel

Esta explicación me llevó a solucionar el problema de un pequeño sitio de prueba alojado en IIS 7.5 en modo integrado. Cuando creé un nuevo proyecto MVC, agregó el httpModule, Microsoft.ApplicationInsights.Web.ApplicationInsightsHttpModule en mi Web.config. Esto se debe a que dejé marcada la opción "Agregar información de la aplicación al proyecto" al crear un nuevo proyecto de aplicación web ASP.NET. Cuando eliminé el httpModule de Web.config, el sitio funcionó sin el error. Establecer validateIntegratedModeConfiguration en falso funcionó, pero eso fue solo un enfoque curita.
iCode

2
Se ha detectado una configuración de ASP.NET que no se aplica en el modo de canalización administrado integrado. Este es otro mensaje de error de Microsoft inútil. ASP.net tiene miles de configuraciones, pero Microsoft no pensó incluir la que causa el error en el texto del error. MS está a cargo de especialistas en marketing en lugar de ingenieros, así que no esperes que las cosas mejoren pronto. :-(
Paul McCarthy

35

Si aún necesita usar el Módulo HTTP, debe configurarlo (.NET 4.0 framework) de la siguiente manera:

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

2
Creo que la propiedad HttpModules en system.web es para ASP 3.5 o anterior. Para ASP 4 o superior, use módulos en system.webserver
Trio Cheung el

1
@HoyCheung es en realidad una cuestión de usar la tubería integrada o clásica, no qué versión de .Net, que decide si usar system.web / httpModules o system.webServer / modules.
Pauli Østerø

29

Me encontré con este problema pero tuve una solución diferente. Implicaba actualizar Control Panel>Administrative Tools>IIS Managery revertir la canalización administrada de mi sitio de aplicaciones de Integrateda Classic.


3
De acuerdo: ¡esta es la mejor opción en lugar de solo ocultar el error! Asegúrese de estar utilizando el grupo de aplicaciones correcto: debe ser clásico no integrado
Swomble el

1
Estoy usando Visual Studio 2012, ¿cómo puedo cambiar el grupo de aplicaciones a clásico?

10
Esta no es una buena solución si desea utilizar todas las nuevas funciones disponibles en Integrated Pipeline. Esto es como decir volver a .NET 2.0 desde 4.0 debido a un problema.
Trevor de Koekkoek

Para hacer esto en el Administrador de IIS, vaya al Application Poolsárbol de la izquierda, haga doble clic en el grupo que desea cambiar y elija el modo de canalización.
Steve Smith

8

Compruebe si hay algún conflicto en su autenticación de IIS. es decir, si habilita la autenticación anónima y la suplantación de ASP.NET, ambos pueden causar el error también.


5

En su web.config asegúrese de que existan estas claves:

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

Además de comprobar Asp.Net Impresonation = Deshabilitar en autenticación de sitio IIS


3

Me encontré con este problema e inspirado por la respuesta de @Jeremy Cook, mordí la bala para descubrir qué demonios causó que el modo integrado IIS 7 no le gustara mi web.config. Aquí está mi escenario:

  1. API web (versión 4.0.030506.0, también conocida como la anterior)
  2. .NET 4.0
  3. Attribute Routing 3.5.6 para Web API [alerta de spoiler: ¡fue este tipo!]

Quería usar el enrutamiento de atributos en un proyecto que (desafortunadamente) tenía que usar .NET 4 y, por lo tanto, no podía usar Web API 2.2 (que necesita .NET 4.5). El bien intencionado paquete NuGet agregó esta sección debajo de la <system.web>sección:

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

[Digo bien, porque esta parte es necesaria en versiones anteriores de IIS]

¡Eliminar esta sección me hizo pasar el HTTP 500.23!

Resumen: Secundo las palabras de Jeremy de que es importante entender por qué las cosas no funcionan en lugar de simplemente "enmascarar el síntoma". Incluso si tiene que enmascarar el síntoma, sabe lo que está haciendo (y por qué) :-)


Gracias. Agregué AttributeRouting, incluido el paquete NuGet del complemento Api Controller, y eliminar la sección que indicaste de web.config resolvió el problema. Sin embargo, estoy un poco preocupado porque mi aplicación web MVC ya estaba usando .NET Framework 4.5.
Robert Oschler

2
@RobertOschler si está en .NET 4.5, ya tiene un enrutamiento de atributos integrado en AFAIK, ¿no debería necesitar este NuGet?
Sudhanshu Mishra

Gracias y basura. Pasaron unas horas hoy para obtener el paquete AttributeRouting que ejecuta NuGet. Lo saqué y deshice todas las "correcciones" de código que agregué para que funcione, y sustituí el atributo Web API 2 Route () por el atributo GET (). Funcionó muy bien. Realmente necesitamos un sistema experto en estos días solo para ayudarnos con todos estos paquetes.
Robert Oschler

2

Esto funcionó para mí:

  1. Eliminar el sitio creado originalmente.
  2. Recrea el sitio en IIS
  3. Solución limpia
  4. Construir solución

Parece que algo salió mal cuando originalmente creé el sitio. Odio las soluciones que son similares a "Reinicie su máquina, luego reinstale Windows" sin saber qué causó el error. Pero, esto funcionó para mí. Rápido y sencillo. Espero que ayude a alguien más.


0

En mi caso, me faltaba dll en la carpeta bin a la que se hacía referencia en el archivo web.config. Por lo tanto, compruebe si estaba utilizando alguna configuración en web.config pero en realidad no tiene dll.

Gracias


0

Me tomó algunas horas resolver esto porque todas las configuraciones que encontré aquí sobre este error eran las mismas, pero aún no funcionaba. El problema era que tenía una carpeta en mi servicio web desde la cual el archivo debería enviarse al dispositivo WinCE, después de convertir esa carpeta en una aplicación con Classic.NetAppPool comenzó a funcionar.


0

El siguiente paso resolvió mi problema:

Abierto CMDSolicitud con privilegios de administrador.

Correr : iisreset.

Espero que esto ayude.


-1

El método para local es el error

imagen


77
No cambie esta configuración a menos que realmente sepa lo que está haciendo. Esta casi nunca es la respuesta correcta.
NickG
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.