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

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?

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>

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:

• ASP.NET 2.0 Rompiendo cambios en IIS 7.0
• Integración ASP.NET con IIS 7
• Descripción general de controladores HTTP y módulos HTTP

* 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.

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 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.

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.

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

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é) :-)

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.

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

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.

El siguiente paso resolvió mi problema:

Abierto CMDSolicitud con privilegios de administrador.

Correr : iisreset.

Espero que esto ayude.

El método para local es el error