J'utilise TeamCity qui à son tour appelle msbuild (.NET 4). J'ai un problème étrange en ce qu'une fois la construction terminée (et peu importe si c'était une construction réussie ou non), msbuild.exe reste ouvert et verrouille l'un des fichiers, ce qui signifie à chaque fois que TeamCity essaie pour effacer son répertoire de travail, il échoue et ne peut pas continuer.
Cela arrive presque à chaque fois.
Je suis vraiment perdu sur celui-ci, alors je vais essayer de fournir le plus de détails possible.
- Le serveur est un Intel Core i7, 2 Go de RAM, avec Windows Server 2008 standard 64 bits SP2.
- Dans TeamCity, le runner msbuild est configuré avec le
/m
paramètre de ligne de commande (ce qui signifie utiliser plusieurs cœurs) - Le fichier en question est TOUJOURS la même DLL externe qui est 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épertoireExternal Tools
dans une structure de chemin similaire qui ne causent jamais ce problème). Actuellement, c'est avec la version d'essai des rapports Telerik, au cas où cela ferait une différence. - Lorsque le problème se produit, il y a toujours plusieurs
msbuild.exe *32
processus répertoriés dans le Gestionnaire de tâches: Je crois qu'il y en a 7. En utilisant Process Explorer, ils ressemblent tous à des processus de niveau supérieur (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 terminent 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 dans Windows (bien que les deux points précédents confirment à peu près que c'est msbuild.exe qui 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é cela?
/m /nr:false
, je vais courir pour quelques builds et voir comment ça se passe. Merci