An ASP.NET se ha detectado una configuración que no se aplica en el modo de canalización administrada integrada

Agregar <validation validateIntegratedModeConfiguration="false"/> aborda el síntoma, pero no es apropiado para todas las circunstancias. Después de haber corrido alrededor de este tema un par de veces, espero ayudar a otros no solo a superar el problema, sino también a entenderlo. (Que se vuelve más y más importante a medida que IIS 6 se desvanece en mito y rumor.)

Antecedentes:

Este problema y la confusión que lo rodea comenzó con la introducción de ASP.NET 2.0 e IIS 7. IIS 6 tenía y sigue teniendo solo un modo de tubería, y es equivalente a lo que IIS 7+ llama modo "Clásico". El segundo modo de canalización, más reciente 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.

• El modo clásico está limitado a ASP.NET canalización que no puede interactuar con la canalización de IIS. Esencialmente, entra una solicitud y si se le ha dicho a IIS 6/Classic, a través de la configuración del servidor, que ASP.NET puede manejarlo a continuación, IIS manos fuera de la solicitud a ASP.NET y sigue adelante. La importancia de esto se puede deducir de un ejemplo. Si tuviera que autorizar el acceso a archivos de imagen estáticos, no sería capaz de hacerlo con un ASP.NET módulo porque la canalización de IIS 6 manejará esas solicitudes por sí misma y ASP.NET nunca verá esas solicitudes porque nunca fueron entregadas.* Por otro lado, autorizando qué usuarios pueden acceder a un .Página ASPX, como una solicitud de Foo.aspx es trivial incluso en IIS 6 / Classic porque IIS siempre entrega esas peticiones a la ASP.NET pipeline. En modo Clásico ASP.NET no sabe lo que no se ha dicho y hay muchas cosas que IIS 6/Classic puede no estar diciendo.

• El modo integrado se recomienda porque ASP.NET los manejadores y módulos pueden interactuar directamente con la canalización de IIS. La canalización de IIS ya no se limita a entregar la solicitud al ASP.NET pipeline, ahora permite ASP.NET código para enganchar directamente en la tubería de IIS y todos los peticiones que le dieron. Esto significa que un ASP.NET el módulo no solo puede observar solicitudes a archivos de imagen estáticos, sino que puede interceptar esas solicitudes y tomar medidas denegando el acceso, registrando la solicitud, etc.

Superando el error:

1. Si está ejecutando una aplicación anterior que se creó originalmente para IIS 6, tal vez 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. Ve adelante no tienes que sentirte mal.

2. Entonces de nuevo tal vez usted está dando a su aplicación un estiramiento facial o estaba chugging a lo largo de muy bien hasta que se instaló una biblioteca de 3rd partido a través de NuGet, manualmente, o por algún otro medio. En ese caso es totalmente posible httpHandlers o httpModules se han añadido a system.web. El resultado es el error que está viendo porque validateIntegratedModeConfiguration por defecto true. Ahora tienes dos opciones:

   1. Elimine los elementos httpHandlers y httpModules de system.web. Hay un par de posibles resultados de esto:
      • Todo funciona bien, un resultado común;
      • Su solicitud continúa quejándose, puede haber una web.config en una carpeta padre de la que está heredando, considere limpiar esa web.config también;
      • Te cansas de eliminar los httpHandlers y httpModules que los paquetes NuGet siguen añadiendo a system.web, haz lo que necesites.
3. Si esas opciones no funcionan o son más problemas de lo que vale, entonces estoy no voy a decirte que no puedes establecer validateIntegratedModeConfiguration a false, pero al menos sabes lo que estás haciendo y por qué importa.

Buena lectura:

• ASP.NET 2.0 Cambios de interrupción en IIS 7.0
• ASP.NET Integración con IIS 7
• Descripción general de los manejadores HTTP y módulos HTTP

* Por supuesto que hay maneras de conseguir todo tipo de cosas extrañas en el ASP.NET pipeline de IIS 6 / Classic a través de encantamientos como asignaciones de comodines, si te gusta ese tipo de cosas.

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>

Me encontré con este problema, pero tenía una solución diferente. Implicaba actualizar el Control Panel>Administrative Tools>IIS Manager y revertir la Canalización Administrada de mi sitio de aplicación de Integrated a Classic.

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

En tu web.config asegúrese de que estas claves existen:

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

Así como comprobar el Asp.Net Impresonation = Disable In IIS Site Authetication

Esto funcionó para mí:

1. Elimine el sitio creado originalmente.
2. Volver a crear el sitio en IIS
3. Solución limpia
4. Solución de compilación

Parece que algo salió mal cuando creé originalmente 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.

Me encontré con este problema e inspirado por la respuesta de @Jeremy Cook, mordí la bala para averiguar qué diablos causó que el modo integrado de IIS 7 no me gustara mi web.config. Este es mi escenario:

1. Web API (versión 4.0.030506.0 también conocida como la antigua)
2. . NET 4.0
3. Attribute Routing 3.5.6 for Web API [spoiler alert: it was this guy!]

Quería usar 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 bajo la sección <system.web>:

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

[Digo bien intencionado, porque esta parte se requiere en versiones anteriores de IIS]

La eliminación de esta sección me llevó más allá de la 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 tienes que enmascarar el síntoma, sabes lo que estás haciendo (y por qué): -)

En mi caso me faltaba dll en la carpeta bin a la que se hacía referencia en la web.archivo de configuración. Así que compruebe si estaba utilizando alguna configuración en la web.config pero en realidad no tienen dll.

Gracias

El método para local Es el error