Temos uma frota de servidores IIS 7.5 que gerenciam nosso produto hospedado. Cada geração do produto recebe seu próprio AppPool e seu próprio site. Cada geração está vinculada ao thegeneration.oursite.com, além de um site sortudo recebe a ligação padrão (que é o cliente realmente atingido, obviamente). Quando estamos prontos para mudar para o novo site, temos uma ferramenta que tenta mudar a ligação padrão da geração antiga para a nova. O padrão para isso é:
Até agora, tudo bem. Nosso código para fazer isso é simples e funciona muito bem.
Bem, quase. Aqui está a coisa: não importa o que fazemos, não importa como tentamos estruturar as coisas, o IIS sempre encerra a nova ligação padrão, reclamando que agora existem dois sites com ligações padrão. Isso acontece independentemente de usarmos o Microsoft.Web.Administration assembly ou editar applicationHost.config . Notavelmente, iniciar manualmente o site após o aviso de conflito funciona muito bem, 100% do tempo, e nem applicationHost.config nem a interface de montagem mostram dois sites com a ligação padrão em nenhum ponto.
Como podemos impedir que o IIS 7.5 seja encerrado quando trocamos ligações padrão? Existe realmente nenhuma maneira de fazer isso?
EDITAR : me pediram para esclarecer o que eu quis dizer com um exemplo, então eu vou passar por uma atualização real de um projeto que estamos gerenciando dessa maneira, Kiln.
Então, digamos que começamos com duas gerações de Kiln que estão ativas: Kiln1.0 e Kiln2.0 . Isso significa que eu tenho AppPools com esses nomes e sites com esses nomes. Basicamente, os clientes estão em Kiln1.0 ; somente nossos testadores e usuários beta estão em Kiln2.0 . As contas de forno pertencem a subdomínios, portanto, para conseguir isso, o site Kiln2.0 tem ligações para, e. *:80:foo.kilnhg.com , *:80:bar.kilnhg.com , etc., e Kiln1.0 site tem a ligação *:80:* para que qualquer pessoa que não esteja explicitamente na geração de testes esteja na nova geração.
Quando quisermos atualizar todos para Kiln2.0 , queremos excluir a associação *:80:* em Kiln1.0 e criá-la em Kiln2.0 . O problema que estou tendo é que todas as maneiras de fazer isso encerra Kiln2.0 , com o IIS afirmando que a ligação está duplicada. É essa ligação específica que está causando o problema.
Parece que você pode ser vítima da latência de atualização da configuração do IIS.
Normalmente, isso pode ser evitado reduzindo o número de etapas (por exemplo, por que limpar e restabelecer as ligações? Basta substituí-las de uma vez e depois confirmar a alteração) ou adicionar estados de espera.
Sim, aguarde estados. {Dormir 10 segundos} no meio do arquivo de lote / script / programa provavelmente funcionaria também.