2012-06-28 12 views
17

Mam debugowanie błędu w moim procesie budowania, który zdarza się sporadycznie, ale nie mogę go bezpośrednio odtworzyć. Używam msbuild z teamcity.Co to jest przyrostowe czyszczenie w msbuild i kiedy jest uruchamiane?

Mam hierarchię zależności takiego:

Some.Interop.dll 
    Dependency-> SharedDllABC.dll 

SomeService.exe 
    Depenendcy-> Some.Interop 

Zazwyczaj ostateczna wykonywalne serwis dostaje w swoim katalogu wydaniu:

Some.Interop 
SharedDllABC.Dll 
ServiceExectuable.exe 

Jednak widzę w naszych dziennikach msbuild że czasami trzeciorzędową zależność zostanie usunięty podczas operacji przyrostowego czyszczenia po utworzeniu wszystkiego, co spowoduje:

Some.Interop 
ServiceExectuable.exe 

Można go zobaczyć tutaj w dzienniku MSBuild:

[src\SomeService\SomeService.csproj] _TimeStampAfterCompile 
[12:32:43]: [src\SomeService\SomeService.csproj] Compile 

// some other targets 

[12:32:43]: [src\SomeService\SomeService.csproj] _CopyFilesMarkedCopyLocal 
[12:32:43]:  [_CopyFilesMarkedCopyLocal] Copy 
[12:32:43]:   [Copy] Copying file from "C:Projects\trunk\src\Some.Interop\bin\Release\Some.Interop.dll" to "bin\Release\Some.Interop.dll". 

// some other targets 

[src\Project\SomeService\SomeService.csproj] IncrementalClean 
[18:54:42]:   [IncrementalClean] Delete 
[18:54:42]:    [Delete] Deleting file "C:\Projects\trunk\src\Project\SomeService\bin\Release\SharedDllABC.dll". 
[18:54:42]:    [Delete] Deleting file "C:\Projects\trunk\src\Project\SomeServiceService\bin\Release\SharedDllABC.pdb". 
[18:54:42]:  [src\Project\SomeService\SomeService.csproj] CoreBuild 
[18:54:42]:  [src\Project\SomeService\SomeService.csproj] AfterBuild 
[18:54:42]:  [src\Project\SomeService\SomeService.csproj] Build 

To jest moja bezpośrednia wyjście msbuild, po prostu zmienił nazwy nazwy projektów/dll pasujące do mojego przykładu. Do czasu wystąpienia tego przyrostowego czyszczenia został już zbudowany model SomeService.csproj. Widać, że nie jest kopiowana. Jednak w innych dziennikach programu msbuild jest poprawnie kopiowany, a następnie przyrostowe czyszczenie go nie usuwa.

Wydaje mi się, że inkrementalne czyszczenie od this post ma na celu wyczyszczenie bibliotek dll, które zostały utworzone z poprzednich kompilacji, ale to nie wyjaśnia, jak ta biblioteka dll nie została zbudowana, gdy przez większość czasu to robi. W visual studio to zawsze działa.

Chyba po prostu chcesz wiedzieć, co dokładnie jest Incremental clean, co powoduje, że kopać, a może jakie rzeczy należy zwracać uwagę podczas debugowania takiej sytuacji (wersje montaż, znaczniki czasu, etc?)

+2

'IncrementalClean' jest realizowany w' C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Microsoft.Common.targets'. Jest w tym sporo logiki ... Jeśli chcesz wiedzieć więcej, dodaj tam pewne odciski - '', a może zobaczysz, co ta logika jest. – Jonathan

+1

Mam bardzo podobne problemy. Czy kiedykolwiek znalazłeś swojego winowajcę? –

+0

Sebastian, nie mogłem tego rozgryźć. W końcu udało mi się stworzyć trudną zależność od tego pliku od projektu, który go potrzebował. To nie było idealne, ale działa. Inne rozwiązania, które wymyślił mój zespół, polegały na utworzeniu testów jednostkowych w celu przetestowania oczekiwanych bibliotek dll, które przynajmniej zapobiegłyby przechodzeniu nieudanych kompilacji do klientów/maszyn testowych. – devshorts

Odpowiedz