Kilka dni temu miałem okazję wygłosić kolejną prelekcję na Wrocławskiej Grupie .NET. Tym razem jako temat wybrałem debugger, który jest dostępny w Visual Studio. Jest to na prawdę kawałek narzędzia, który możemy wykorzystać dość sprawnie na naszą korzyść jeśli tylko wiemy gdzie szukać.
Prezentacja to tak na prawdę zbiór tego co publikowałem w ostatnich czasach na blogu jak również na devPytania tak więc jeśli ktoś regularnie czyta bloga - zapewne nie znajdzie zbyt wiele nowości.
Powiedziałem o:
- ustawieniach w VS, systemowych (Dźwiękowy breakpoint) oraz rejestrowych (o tym będzie jeszcze post)
- Atrybutach: DebuggerDisplay oraz DebuggerStepThrough
- breakpointach i tracepoint'ach
- DebuggerDisplay dla typów wbudowanych
- DebuggerVisualizers
- MakeObject ID w okienku Watch
- Sos (choć tu się nie udało w VS - VS odmówiło posłuszeństwa raportując dziwnym błędem)
- Exception Assistant (jak możemy dodać obsługę naszych własnych wyjątków w nim)
- Breakpoint na funkcji, aby podpiąć się do do auto property lub event handlerów.
- Warunkowym breakpoint'ie i jego nieszablonowym zastosowaniu
Z ciekawostek wspomniałem o:
- Debugger Canvas
- własnym debugerze pisanym przez Sebastiana Solnicę
Przykłady i prezentacja (niewiele w niej jest) do pobrania. W razie pytań zachęcam do kontaktu.
_512_513_resized.png)
5 komentarze:
Duzo bylo osob? Byly jakies pytania? Temat wydaje sie mocno niszowy...
Michał: mało osób (ale to chyba nie temat :] - styczeń zwykle jest słabo obsadzony poza tym mieliśmy sesję w dzień protestów przeciwko ACTA), pytań sporo. Akurat osoby były zainteresowane innymi rzeczami niż te które przygotowałem :)
hej Paweł,
Dzięki za ciekawostkę na temat mindbg - trochę zarzuciłem ten temat ostatnimi czasy, ale teraz mam motywację żeby do niego wrócić:) Mam nadzieję, że kiedyś będzie okazja żeby uczestniczyć w Twojej prezentacji. A z ciekawości kontynuując pytanie Michała: A mógłbyś napisać o co pytali uczestnicy w tematyce debuggingu?
Pozdrawiam,
Sebastian
@Michał, @Sebastian:
Pytań było trochę w stylu czy będę mówił o xxx, albo czy wiem, że to i to da się też tak.
Przy okazji Object ID jak się zachowuje GC w takiej sytuacji gdy przypinamy sobie obiekt i jest on widoczny poza swoim scopem.
Ogólnie było trochę dyskusji bo mimo, że zgadzam się, że temat niszowy to przecież każdy z nas robi to praktycznie codziennie i warto wiedzieć jak usprawnić pracę jeśli będzie taka potrzeba.
Jeśli coś sobie jeszcze przypomnę to postaram się napisać.
Paweł, jeśli chodzi o Object ID to prawdopodobnie VS tworzy sobie uchwyt (wskaźnik) do obiektu na stercie i sprawdza czy obiekt ten jest ciągle żywy. Czyli mniej więcej to, co robi kod poniżej:
GCHandle h = GCHandle.Alloc(new Object(), GCHandleType.WeakTrackResurrection);
// should be true
Console.WriteLine("h.Target != null: {0}", h.Target != null);
// force garbage collection
GC.Collect();
// should be false
Console.WriteLine("h.Target != null: {0}", h.Target != null);
Jeśli kod ten miałby być w jeden metodzie, trzeba pamiętać żeby skompilować z /optimize+ (domyślnie w trybie debug CLR trzyma referencje do obiektów do końca wywołania metody i nie pozwala na ich usunięcie ze sterty). GCHandle z typem Weak nie wpływa na pracę Garbage Collector-a, więc tworzenie object ID jest bezpiecznym sposobem sprawdzania żywotności obiektów:)
Pozdrawiam,
Sebastian
Prześlij komentarz