Não tenho certeza se isso pertence aqui ou em SO, mas aqui vai de qualquer maneira ...
Temos um servidor CruiseControl.NET que executa aplicações ou aplicativos noturnos e publica a saída resultante na instância do IIS na mesma caixa - isso funciona como uma implantação de teste para controle de qualidade.
Tudo tem funcionado bem por meses até que nos mudamos para um novo servidor (Win2003 R2 SP1) - na verdade, uma VM.
Agora, sempre que a compilação noturna é publicada no IIS, recebemos um erro no navegador informando O compilador falhou com o código de erro 128 . Isso nunca aconteceu no servidor antigo!
Rodar o aspnet_regiis -i irá colocar o site online novamente, mas estou confuso sobre o motivo de o IIS parecer ter esquecido tudo sobre o .NET como resultado de uma simples cópia de arquivo.
Revisei o estágio de publicação do processo de criação e movi do script em lote antigo para um script nAnt 'mais limpo', mas o problema continua.
Se eu executar o comando acima, limpar os logs de eventos e acessar o site, um novo evento será exibido:
The configuration information of the performance library
"C:\WINDOWS\system32\infoctrs.dll" for the "InetInfo" service does not match
the trusted performance library information stored in the registry.
The functions in this library will not be treated as trusted.
Mas o site ainda é carregado sem problemas. Se eu, então, executar um dos scripts de publicação (.bat ou .build) e, em seguida, acessar o site, outro evento idêntico será exibido e o erro de compilação será exibido (executando aspnet_regiis, porém, corrija-o).
Se eu excluir manualmente os arquivos antigos e copiar os novos, mais uma vez o erro do compilador será exibido no navegador.
Agora, a solução rápida é executar o aspnet_regiis como parte do script de construção, mas, francamente, isso só cheira mal.
[Editar 12/11/09]: Eu tenho chutado isso por um tempo agora e ainda não sei realmente porque está acontecendo. Eu reinstalei o IIS e o .NET 2.0 & 3.0 (3.5 não é necessário!) Mas o problema persistiu. Por fim, tentei implantar o aplicativo usando arquivos criados por meio de uma compilação 'Release' (em vez de 'Debug') e isso parece ter resolvido o problema - mas não sei por quê.
Eu vou descobrir amanhã de manhã depois que as construções noturnas tiverem corrido com raiva, então espero ter boas notícias esperando por mim. Assumindo que este é o problema, por que deveria fazer a diferença? Este processo estava funcionando bem por meses no servidor físico - por que isso deveria estar causando problemas na VM.?
Alguém tem alguma ideia, sugestão ou solução?
Agradecemos antecipadamente