msbuild.exe en restant ouvert, en verrouillant les fichiers

J’utilise TeamCity qui invoque à son tour msbuild (.NET 4). J’ai un problème étrange dans la mesure où une fois la construction terminée (et cela ne semble pas avoir d’importance si la construction a été réussie ou non), msbuild.exe rest ouvert et verrouille l’un des fichiers, ce qui signifie pour effacer son répertoire de travail, il échoue et ne peut pas continuer.

Cela se produit presque chaque fois.

Je suis vraiment perdu sur celui-ci, alors je vais essayer de fournir autant de détails que possible.

Server est un processeur Intel Core i7 de 2 Go avec Windows Server 2008 standard 64 bits SP2.
Dans TeamCity, le runner msbuild est configuré avec le paramètre de ligne de commande /m (ce qui signifie utiliser plusieurs cœurs)
Le fichier en question est TOUJOURS la même DLL externe référencée dans l’un des projets .NET, dans le chemin External Tools\Telerik\Telerik.Reporting.Dll . (Il existe plusieurs autres fichiers .DLL inclus dans le répertoire External Tools dans une structure de chemin similaire qui ne cause jamais ce problème). Actuellement, c’est avec la version d’essai de Telerik Reports, au cas où cela ferait une différence.
Lorsque le problème se produit, il y a toujours plusieurs processus msbuild.exe *32 répertoriés dans le Gestionnaire des tâches: Je crois qu’il y en a 7. En utilisant Process Explorer, ils ressemblent tous à des processus de premier niveau (pas de parents). Ils utilisent tous de 20 à 50 Mo de RAM et 0,0% de CPU.
Si j’attends 1 à 3 minutes, les processus msbuild.exe se ferment d’eux-mêmes et TeamCity peut alors mettre à jour correctement le répertoire de travail.
Si je termine manuellement les processus msbuild, la mise à jour de TeamCity fonctionnera à nouveau immédiatement.
Les services d’indexation sont désactivés sous Windows (bien que les deux points précédents confirment à peu près que msbuild.exe est à l’origine du problème).
Il n’y a pas de propriétés spéciales sur Telerik.reporting.dll. La seule propriété SVN est svn:mime-type = application/octet-stream

Quelqu’un a-t-il déjà rencontré ça?

Utilisez msbuild avec /nr:false .

En bref: MSBuild essaie de faire beaucoup de choses pour être rapide, surtout avec des builds parallèles. Il générera beaucoup de “nœuds” – des processus msbuild.exe individuels qui peuvent comstackr des projets, et comme les processus mettent un peu de temps à se développer, une fois la construction terminée, ces processus restnt bloqués (par défaut, pendant 15 minutes, je pense) ), de sorte que si vous construisez à nouveau rapidement, ces nœuds peuvent être “réutilisés” et enregistrer le coût de configuration du processus. Mais vous pouvez désactiver ce comportement en désactivant nodeReuse avec l’option de ligne de commande susmentionnée.

Voir également:

MSBuild et ConHost restnt en mémoire après la construction parallèle
Référence de la ligne de commande MSBuild
Générations parallèles qui ne bloquent pas les DLL de tâches MSBuild personnalisées
Réutilisation des noeuds dans MultiProc MSBuild

Pour désactiver la réutilisation du noeud dans Visual Studio, vous devez utiliser une variable d’environnement:

 MSBUILDDISABLENODEREUSE=1