Web.Config Caindo para trás para a Global config na Web Farm

Question

Este problema tem vários de nós perplexo no escritório. Estamos todos de novo para implantar ASP.NET aplicativos para uma fazenda web, e estou fora de ideias frescas.

Temos uma fazenda web, eo aplicativo é copiado para todos eles. No entanto, nós estamos tendo um problema ..

Uma exceção está sendo lançada quando tentar obter as configurações de appSettings. Ao investigar mais, verifica-se o nó realmente não está usando o Web.Config local, mas ele cair de volta para o Web.Config na pasta .NET framework (provámos isso adicionando chaves lá, que aparecem em uma página de teste).

Eu devo estar faltando alguma coisa, porque o meu entendimento é que, desde que o arquivo está lá, IIS deve usar isso! Um dos servidores parece funcionar bem!

Aqui está uma lista do que temos confirmado:

• O arquivo de configuração está no diretório do aplicativo.
• o conteúdo do arquivo de Said é correta.
• Ao visualizar o arquivo de IIS> Site> Propriedades> ASP.NET> Editar configuração o conteúdo correto é mostrado.

No entanto, em tempo de execução do arquivo que é utilizado é o global (windows\ms .net\framework\v2\config\web.config).

Alguém tem alguma sugestão sobre o que pode estar acontecendo de errado? Apreciar toda a ajuda que puder conseguir!

Graças.

Rob

Answer 1

Em primeiro lugar, muito obrigado para os caras que responderam, eu aprecio a ajuda!

Apenas uma atualização sobre esta questão. Era uma pergunta difícil!

Acontece que, não havia nada de errado com o código, ou a configuração.

Parece que algo estranho estava acontecendo com o farm de servidores (que eu absolutamente não tem controle sobre ou acesso a). O administrador de sistemas re-construída a fazenda, re-implantado a solução e tudo muito bem trabalhado.

Eu acho que nós nunca vai saber o que estava errado, mas pelo menos sabemos que não era uma questão de desenvolvimento!

Obrigado novamente, Rob

Answer 2

Esta é a hierarquia para a configuração do ASP.NET. Talvez isso poderia ajudar a entender quais configurações substituir uns aos outros.

Servidor

Machine.config: O arquivo Machine.config contém o esquema ASP.NET para todos os aplicativos Web no servidor. Este arquivo está no topo da hierarquia merge configuração.

Root Web

Web.config: O arquivo Web.config para o servidor é armazenado no mesmo diretório que o arquivo Machine.config e contém os valores padrão para a maioria das seções de configuração system.web. Em tempo de execução, este arquivo é o segundo resultante da fusão de topo na hierarquia de configuração.

site

Web.config:. O arquivo Web.config para um site específico contém configurações que se aplicam ao site da Web e herdam para baixo através de todas as aplicações ASP.NET e subdiretórios do site

ASP.NET diretório raiz do aplicativo

Web.config:. O arquivo Web.config para uma aplicação específica ASP.NET está localizado no diretório raiz do aplicativo e contém configurações que se aplicam ao aplicativo Web e herdam para baixo através de todos os subdiretórios no seu ramo

ASP.NET aplicativo subdiretório

Web.config:. O arquivo Web.config para um subdiretório do aplicativo contém as configurações que se aplicam a este subdiretório e herdam para baixo através de todos os subdiretórios no seu ramo

diretório de aplicativos do cliente

ApplicationName.config:. O arquivo ApplicationName.config contém configurações para um aplicativo cliente do Windows (não um aplicativo da Web)

---

Compreender quais arquivos e pastas ASP.NET são herdadas por pastas e aplicativos é muito importante para o desenvolvimento e solução de problemas.

Aqui está um breve resumo:

• arquivos web.config herdar todo o caminho até a árvore, passado todos os limites de aplicação.
• global.asax só vive dentro de sua aplicação
• / bin e / App_ {pastas} só vivem dentro de sua aplicação

Então, isso significa que definir nada no arquivo web.config raiz herdarão para baixo todo o site, mesmo se algumas pastas são marcadas como aplicações.

Onde isso fica confuso é se o arquivo web.config tem referências para os conjuntos, mas sub-aplicações não tem essas assembléias. Por exemplo, digamos que você tem um HTTP módulo configurado na raiz do site e referenciado a partir do arquivo local web.config. Se você tem um sub-aplicativo chamado / subpasta que é marcado como um aplicativo, em seguida, / subpasta vai tentar carregar o HTTP Handler de / subpasta / bin. Uma vez que não existe, um erro será lançada.

Existem várias maneiras de contornar isso. Provavelmente o mais limpo se o manipulador de HTTP não é necessário in / subpasta é de 'remoção' de referência, adicionando uma cláusula no arquivo /subfolder/web.config. Você pode fazer isso com. Aqui está um exemplo de como remover um HTTP Module em uma subpasta:

<httpModules>
  <remove name="ErrorLog"/>
</httpModules>

Aqui está o que o web.config local pode parecer:

<httpModules>
      <add name="ErrorLog"  type="GotDotNet.Elmah.ErrorLogModule, GotDotNet.Elmah, Version=1.0.5527.0, Culture=neutral, PublicKeyToken=978d5e1bd64b33e5" />
</httpModules>print("code sample");

Answer 3

Desde que você diga nos comentários, eu sugiro ir com "Try and Error".

O que acontece, se você inserir uma entrada errada por finalidade? Será que a aplicação falhar ou não isso afeta alguma coisa?

Tente copiar o conteúdo e, em seguida, apagar e recriar esse arquivo a partir do zero.