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?)
'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
Mam bardzo podobne problemy. Czy kiedykolwiek znalazłeś swojego winowajcę? –
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