Ik gebruik TeamCity dat op zijn beurt msbuild (.NET 4) aanroept. Ik heb een vreemd probleem dat nadat een build is voltooid (en het lijkt niet uit te maken of het een succesvolle build was of niet), msbuild.exe open blijft en een van de bestanden vergrendelt, wat betekent dat elke keer dat TeamCity het probeert om de werkmap te wissen, mislukt het en kan het niet doorgaan.
Dit gebeurt bijnaelke keer.
Ik ben het hier echt niet mee eens, dus ik zal proberen zo veel mogelijk details te geven.
- Server is een Intel Core i7, 2 GB ram, met Windows Server 2008 standaard 64-bit SP2.
- In TeamCity is de msbuild-runner geconfigureerd met de opdrachtregelparameter
/m(wat betekent dat meerdere kernen moeten worden gebruikt) - Het bestand in kwestie is ALTIJDdezelfde externe DLL waarnaar wordt verwezen in een van de .NET-projecten, in het pad
External Tools\Telerik\Telerik.Reporting.Dll. (Er zijn verschillende andere .DLL-bestanden in de mapExternal Toolsin een vergelijkbare padstructuur die dit probleem nooit veroorzaken). Momenteel is dit met de proefversie van Telerik-rapporten, voor het geval dat enig verschil maakt. - Als het probleem zich voordoet, worden er altijd verschillende
msbuild.exe *32-processen vermeld in Taakbeheer: ik geloof dat er 7 zijn. Als u Process Explorer gebruikt, zien ze er allemaal uit als processen op het hoogste niveau (geen ouders). Ze gebruiken allemaal 20-50 MB ram en 0,0% CPU. - Als ik 1-3 minuten wacht, worden de msbuild.exe-processen vanzelf afgesloten en kan TeamCity de werkdirectory dan correct bijwerken.
- Als ik de msbuild-processen handmatig beëindig, werkt de update van TeamCity onmiddellijk weer.
- Indexeringsservices zijn uitgeschakeld in Windows (hoewel de voorgaande twee punten vrijwel bevestigen dat msbuild.exe het probleem veroorzaakt).
- Er zijn geen speciale eigenschappen op Telerik.reporting.dll. De enige SVN-eigenschap is
svn:mime-type = application/octet-stream
Is iemand dit eerder tegengekomen?
Antwoord 1, autoriteit 100%
Gebruik msbuildmet /nr:false.
Kort samengevat: MSBuild probeert veel dingen te doen om snel te zijn, vooral met parallelle builds. Het zal veel “knooppunten” voortbrengen – individuele msbuild.exe-processen die projecten kunnen compileren, en aangezien processen wat tijd nodig hebben om op te starten, blijven deze processen hangen nadat de build is voltooid (standaard 15 minuten, denk ik ), zodat als u binnenkort opnieuw gaat bouwen, deze knooppunten kunnen worden “hergebruikt” en de kosten voor het instellen van het proces kunnen worden bespaard. Maar je kunt dat gedrag uitschakelen door nodeReuse uit te schakelen met de eerder genoemde opdrachtregeloptie.
Zie ook:
-
MSBuild en ConHost blijven in het geheugen na parallel bouwen
-
Parallelle builds die geen aangepaste MSBuild-taak-DLL’s vergrendelen
Antwoord 2, autoriteit 35%
Als u het hergebruik van knooppunten in Visual Studio wilt uitschakelen, moet u een omgevingsvariabele gebruiken:
MSBUILDDISABLENODEREUSE=1