msbuild.exe permanecendo aberto, bloqueando arquivos

Eu uso o TeamCity que por sua vez invoca msbuild (.NET 4). Eu tenho um problema estranho em que depois que uma compilação é concluída (e não parece importar se foi uma compilação bem-sucedida ou não), msbuild.exe permanece aberto e bloqueia um dos arquivos, o que significa que toda vez que o TeamCity tenta para limpar seu diretório de trabalho, ele falha e não pode continuar.

Isso acontece quase todas as vezes.

Estou realmente perdido neste, então tentarei fornecer o máximo de detalhes possível.

• O servidor é um Intel Core i7, 2 GB de RAM, com o padrão Windows Server 2008 SP2 de 64 bits.
• No TeamCity, o msbuild runner é configurado com o /mparâmetro de linha de comando (o que significa usar múltiplos núcleos)
• O arquivo em questão é SEMPRE a mesma DLL externa que é referenciada em um dos projetos .NET, no caminho External Tools\Telerik\Telerik.Reporting.Dll. (Existem vários outros arquivos .DLL incluídos no External Toolsdiretório em uma estrutura de caminho semelhante que nunca causa esse problema). Atualmente, está com a versão de teste dos relatórios da Telerik, caso isso faça alguma diferença.
• Quando o problema acontece, sempre há vários msbuild.exe *32processos listados no gerenciador de tarefas: Eu acredito que há 7. Usando o Process Explorer, todos eles parecem processos de nível superior (sem pais). Todos estão usando de 20 a 50 MB de RAM e 0,0% de CPU.
• Se eu esperar de 1 a 3 minutos, os processos msbuild.exe são encerrados por conta própria e o TeamCity pode atualizar o diretório de trabalho adequadamente.
• Se eu encerrar manualmente os processos msbuild, a atualização do TeamCity funcionará novamente imediatamente.
• Os serviços de indexação estão desativados no Windows (embora os dois pontos anteriores confirmem que é msbuild.exe que está causando o problema).
• Não há propriedades especiais em Telerik.reporting.dll. A única propriedade SVN ésvn:mime-type = application/octet-stream

Alguém já passou por isso antes?

Use msbuildcom /nr:false.

Resumidamente: o MSBuild tenta fazer muitas coisas para ser rápido, especialmente com compilações paralelas. Ele vai gerar muitos "nós" - processos msbuild.exe individuais que podem compilar projetos e, como os processos demoram um pouco para girar, depois que a compilação é feita, esses processos ficam pendurados (por padrão, por 15 minutos, eu acho ), de modo que, se acontecer de você construir novamente em breve, esses nós possam ser "reutilizados" e economize no custo de configuração do processo. Mas você pode desabilitar esse comportamento desligando o nodeReuse com a opção de linha de comando mencionada.

Veja também:

• MSBuild e ConHost permanecem na memória após a construção paralela

• Referência de linha de comando do MSBuild

• Compilações paralelas que não bloqueiam DLLs de tarefas MSBuild personalizadas

• Reutilização de nó em MultiProc MSBuild

Para desativar a reutilização de nós no Visual Studio, você deve usar uma variável de ambiente:

MSBUILDDISABLENODEREUSE=1