Foi detectada uma configuração do ASP.NET que não se aplica no modo de pipeline gerenciado integrado

Instalei o DotNetOpenAuth SDK-3.4.5.10201.vsix e não consigo fazê-lo funcionar. Funciona localmente (quando executo como localhost), mas quando tento publicá-lo não está funcionando.

A mensagem de erro do IIS que recebo é

Resumo do erro Erro
HTTP 500.22 - Erro interno do servidor
Foi detectada uma configuração do ASP.NET que não se aplica ao modo de pipeline gerenciado integrado.

E

Module       ConfigurationValidationModule  
Notification BeginRequest  
Handler      StaticFile  
Error Code   0x80070032  

então, existem algumas sugestões sobre como resolver o problema:

Coisas que você pode tentar:

• Migrar a configuração para a system.webServer/modulesseção. Você pode fazer isso manualmente ou usando o AppCmd ​​na linha de comando - por exemplo %SystemRoot%\system32\inetsrv\appcmd migrate config "Default Web Site/",. Usar AppCmdpara migrar seu aplicativo permitirá que ele funcione no modo Integrado e continue no modo Clássico e nas versões anteriores do IIS.

• Se você tiver certeza de que não há problema em ignorar esse erro, ele pode ser desativado configurando-se system.webServer/validation@validateIntegratedModeConfiguration como false.

• Como alternativa, alterne o aplicativo para um pool de aplicativos no modo Clássico - por exemplo %SystemRoot%\system32\inetsrv\appcmd set app "Default Web Site/" /applicationPool:"Classic .NET AppPool",. Faça isso apenas se você não conseguir migrar seu aplicativo.
  (Defina "Site padrão" e "Classic .NET AppPool" como o caminho e o nome do pool de aplicativos)

Mas o problema é que não tenho acesso ao servidor ISS, pois não sou o proprietário. Existe alguma maneira de resolver isto?

A 2 ^ª opção é o que deseja.

No seu web.config, verifique se essas chaves existem:

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

A adição <validation validateIntegratedModeConfiguration="false"/>aborda o sintoma, mas não é apropriado para todas as circunstâncias. Tendo resolvido esse problema algumas vezes, espero ajudar outras pessoas não apenas a superar o problema, mas a entendê-lo. (Que se torna cada vez mais importante à medida que o IIS 6 se transforma em mito e boato.)

Fundo:

Esse problema e a confusão em torno dele começaram com a introdução do ASP.NET 2.0 e IIS 7. O IIS 6 tinha e continua a ter apenas um modo de pipeline e é equivalente ao que o IIS 7+ chama de modo "Clássico". O segundo, mais recente e recomendado modo de pipeline para todos os aplicativos em execução no IIS 7+ é chamado modo "Integrado".

Então, qual a diferença? A principal diferença é como o ASP.NET interage com o IIS.

• Modo clássicoé limitado a um pipeline do ASP.NET que não pode interagir com o pipeline do IIS. Essencialmente, uma solicitação é recebida e se o IIS 6 / Classic foi informado, por meio da configuração do servidor, que o ASP.NET pode lidar com isso, o IIS entrega a solicitação ao ASP.NET e segue em frente. O significado disso pode ser obtido a partir de um exemplo. Se eu autorizasse o acesso a arquivos de imagem estáticos, não seria possível fazê-lo com um módulo ASP.NET porque o pipeline do IIS 6 manipulará essas solicitações e o ASP.NET nunca verá essas solicitações porque nunca foram entregues . * Por outro lado, autorizar quais usuários podem acessar uma página .ASPX, como uma solicitação para Foo.aspx, é trivial, mesmo no IIS 6 / Classic, porque o IIS sempre entrega essas solicitações ao pipeline do ASP.NET. No modo Clássico, o ASP.NET não sabe o que tem.

• O modo integrado é recomendado porque os manipuladores e módulos do ASP.NET podem interagir diretamente com o pipeline do IIS. O pipeline do IIS não entrega mais a solicitação ao pipeline do ASP.NET, agora permite que o código do ASP.NET seja conectado diretamente ao pipeline do IIS e a todas as solicitações que o atingem. Isso significa que um módulo ASP.NET não pode apenas observar solicitações para arquivos de imagem estáticos, mas também pode interceptar essas solicitações e tomar medidas negando o acesso, registrando a solicitação, etc.

Superando o erro:

1. Se você estiver executando um aplicativo antigo que foi originalmente criado para o IIS 6, talvez o tenha movido para um novo servidor, pode não haver absolutamente nada de errado em executar o pool de aplicativos desse aplicativo no modo Clássico. Vá em frente, você não precisa se sentir mal.

2. Por outro lado, talvez você esteja aplicando um lifting facial no seu aplicativo ou ele estava funcionando perfeitamente até você instalar uma biblioteca de terceiros via NuGet, manualmente ou por outros meios. Nesse caso, é totalmente possível httpHandlersou httpModulesfoi adicionado a system.web. O resultado é o erro que você está vendo por validateIntegratedModeConfigurationpadrão true. Agora você tem duas opções:

   1. Remova os elementos httpHandlerse httpModulesde system.web. Existem alguns resultados possíveis disso:
      • Tudo funciona bem, um resultado comum;
      • Seu aplicativo continua reclamando; pode haver um web.config na pasta pai da qual você está herdando; considere limpar esse web.config também;
      • Você se cansa de remover httpHandlerse httpModulesque os pacotes NuGet continuam aumentando system.web, ei, faça o que você precisa.
3. Se essas opções não funcionam ou são mais problemas do que vale a pena, então eu não vou dizer-lhe que você não pode definir validateIntegratedModeConfigurationa false, mas pelo menos você sabe o que está fazendo e por que é importante.

Boas leituras:

• Alterações de quebra do ASP.NET 2.0 no IIS 7.0
• Integração do ASP.NET com o IIS 7
• Visão geral sobre manipuladores HTTP e módulos HTTP

* É claro que existem maneiras de colocar todo tipo de coisas estranhas no pipeline do ASP.NET no IIS 6 / Classic por meio de encantamentos como mapeamentos de caracteres curinga , se você gosta desse tipo de coisa.

Se você ainda precisar usar o módulo HTTP, precisará configurá-lo (estrutura do .NET 4.0) da seguinte maneira:

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

Corri para esse problema, mas tinha uma correção diferente. Isso envolvia a atualização Control Panel>Administrative Tools>IIS Managere a reversão do pipeline gerenciado do meu site de aplicativos de Integratedpara Classic.

Verifique se há algum conflito na autenticação do IIS. ou seja, você habilita a autenticação anônima e a representação do ASP.NET, ambas também podem causar o erro.

No seu web.config, verifique se essas chaves existem:

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

Além de verificar a impressão asp.net = desabilitar na autenticação de site do IIS

Eu me deparei com esse problema e, inspirado na resposta de Jeremy Cook, mordi a bala para descobrir o que diabos fazia o modo integrado do IIS 7 não gostar do meu web.config. Aqui está o meu cenário:

1. API Web (versão 4.0.030506.0, também conhecida como antiga)
2. .NET 4.0
3. Roteamento de atributos 3.5.6 para API da Web [alerta de spoiler: era esse cara!]

Eu queria usar o roteamento de atributos em um projeto que (infelizmente) precisava usar o .NET 4 e, portanto, não podia usar a API da Web 2.2 (que precisa do .NET 4.5). O pacote NuGet bem intencionado adicionou esta seção na <system.web>seção:

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

[Eu digo bem-intencionado, porque esta parte é necessária em versões mais antigas do IIS]

A remoção desta seção me levou além do HTTP 500.23 !!

Resumo: Segundo as palavras de Jeremy, é importante entender por que as coisas não funcionam, em vez de apenas "mascarar o sintoma". Mesmo se você tiver que mascarar o sintoma, você sabe o que está fazendo (e por que) :-)

Isso funcionou para mim:

1. Exclua o site criado originalmente.
2. Recrie o site no IIS
3. Solução limpa
4. Solução de compilação

Parece que algo foi para o sul quando eu criei o site. Detesto soluções semelhantes a "Reinicie sua máquina e reinstale o Windows" sem saber o que causou o erro. Mas, isso funcionou para mim. Rápido e simples. Espero que isso ajude mais alguém.

No meu caso, estava faltando DLL na pasta bin, que foi referenciada no arquivo web.config. Portanto, verifique se você estava usando alguma configuração no web.config, mas na verdade não possui dll.

obrigado

Levei algumas horas para resolver isso, porque todas as configurações que encontrei aqui sobre esse erro foram as mesmas, mas ainda não funcionaram. O problema era que eu tinha uma pasta no meu serviço web a partir da qual o arquivo deveria ser enviado para o dispositivo WinCE, depois de converter essa pasta em um aplicativo com o Classic.NetAppPool, ele começou a funcionar.

A etapa abaixo resolveu meu problema:

CMDPrompt aberto com privilégios de administrador.

Corre : iisreset.

Espero que isto ajude.

O método para local É o erro