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

Instalé DotNetOpenAuth SDK-3.4.5.10201.vsix y no puedo hacer que funcione. Funciona localmente (cuando funciono como localhost) pero cuando bash publicarlo no funciona.

El mensaje de error de IIS que obtengo es

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

Y

Module ConfigurationValidationModule Notification BeginRequest Handler StaticFile Error Code 0x80070032 

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

Cosas que puedes intentar:

  • Migre la configuración a la sección system.webServer/modules . Puede hacerlo manualmente o utilizando AppCmd ​​desde la línea de comando, por ejemplo, %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/" . El uso de AppCmd para 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 configurando system.webServer/validation@validateIntegratedModeConfiguration en false.

  • Alternativamente, cambie la aplicación a un grupo de aplicaciones de 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 “Pool de aplicaciones .NET clásico” en la ruta de la aplicación y el nombre del conjunto de aplicaciones)

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

La segunda opción es la que desea.

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

      

Al agregar aborda el síntoma, pero no es apropiado para todas las circunstancias. Después de haber tratado este tema varias veces, espero ayudar a otros no solo a superar el problema sino a entenderlo. (Lo cual se vuelve cada vez más importante a medida que IIS 6 se desvanece en el mito y el rumor).

Fondo:

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, más nuevo y recomendado modo de canalización para todas las aplicaciones que se ejecutan en IIS 7+ se denomina 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 una interconexión de ASP.NET que no puede interactuar con la interconexión de IIS. Básicamente se recibe una solicitud y si se ha informado a IIS 6 / Classic, a través de la configuración del servidor, que ASP.NET puede manejarlo, IIS entrega 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 de ASP.NET 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, autorizar a los usuarios a 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 el 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.

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

Superando el error:

  1. Si está ejecutando una aplicación anterior que fue originalmente creada para IIS 6, tal vez la haya movido a un nuevo servidor, no puede haber absolutamente nada de malo en ejecutar el grupo de aplicaciones de esa aplicación en el modo Clásico. Adelante, no tienes que sentirte mal.
  2. Por otra parte, tal vez le está dando una aplicación de estiramiento facial a su aplicación o simplemente funcionaba bien hasta que instaló una biblioteca de terceros a través de NuGet, manualmente o por otros medios. En ese caso, es completamente posible que httpHandlers o httpModules se hayan agregado a system.web . El resultado es el error que está viendo porque validateIntegratedModeConfiguration true . Ahora tienes dos opciones:

    1. Elimina los elementos httpHandlers y httpModules de system.web . Hay un par de resultados posibles de esto:
      • Todo funciona bien, un resultado común;
      • Su aplicación sigue quejándose, puede haber un archivo web.config en la carpeta principal de la que está heredando, considere limpiar ese web.config también;
      • Te cansas de eliminar los httpHandlers y los httpModules que los paquetes NuGet siguen agregando al system.web , haz lo que necesites.
  3. Si esas opciones no funcionan o son más problemáticas de lo que vale, no voy a decirte que no puedes establecer validateIntegratedModeConfiguration en false , pero al menos sabes lo que estás haciendo y por qué es importante.

Buenas lecturas:

  • ASP.NET 2.0 rompiendo cambios en IIS 7.0
  • Integración ASP.NET con IIS 7
  • Controladores HTTP y descripción general de los módulos HTTP

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

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 Control Panel>Administrative Tools>IIS Manager mi sitio de aplicaciones desde Integrated a Classic .

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

       

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

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

      

Además de verificar Asp.Net Impresonation = Disable In IIS Site Authetication

Esto funcionó para mí:

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

Parece que algo se fue al sur cuando originalmente creé el sitio. Odio las soluciones que son similares a “Reiniciar su máquina, luego vuelva a instalar Windows” sin saber qué causó el error. Pero, esto funcionó para mí. Rápido y simple. Espero que ayude a alguien más.

Me encontré con este problema e inspirado por la respuesta de @Jeremy Cook, mordí la viñeta para descubrir qué diablos hacía que el modo integrado de IIS 7 no le gustara mi web.config. Aquí está mi escenario:

  1. Web API (versión 4.0.030506.0 alias la anterior)
  2. .NET 4.0
  3. Attribute Routing 3.5.6 para Web API [alerta de spoiler: ¡era este chico!]

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

      

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

Eliminar esta sección me permitió superar HTTP 500.23 !!

Resumen: repito 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é) 🙂

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

Gracias

El método para local es el error

imagen