Debugowanie dowolnych bibliotek, czyli dotPeek może być przydatny (i mój blog też :P)

Właściwie nigdy wcześniej nie zastanawiałem się nad debugowaniem kodu .NET frameworka. Zawsze chyba wychodziłem z założenia, że pewno łatwo się nie da, więc nawet nie próbowałem. Z drugiej strony, nigdy nie miałem dużej potrzeby, aby to robić, więc i nie drążyłem tematu. Ostatnio (podczas moich przygód z lokalizowaniem komunikatów walidacyjnych) działy się niezrozumiałe dla mnie rzeczy, więc chciałem się dowiedzieć co tam się właściwie dzieje i nawet mi się udało - chociaż łatwo nie było.

Cel

Moją zasadniczą potrzebą było debugowanie binarek dotnetowych, zarówno zainstalowanych w GAC razem z całym frameworkiem, jak i zainstalowanych w solucji przez NuGeta. Symbole do tych pierwszych można niby pobrać z Microsoft Symbol Server, ale do tych drugich przydaje się już dotPeek. Jak się okazuje, narzędzie to potrafi generować pliki PDB dla dowolnych zestawów .NET. To może być przydatne, np. w sytuacji, gdy chcemy debugować kod firmy trzeciej, która nie dostarczyła nam symboli debugowania ani kodu źródłowego. (Albo, gdy zgubimy źródła własnej aplikacji. ;))

Co jest potrzebne

Do debugowania dowolnych bibliotek dll w Visual Studio przy pomocy dotPeeka potrzebne są:

1. Visual Studio
2. dotPeek
3. Dużo czasu na eksperymenty albo przeczytanie tego posta.

Debugowanie kodu .NET frameworka z GAC

W Tools -> Options -> Debugging trzeba przede wszystkim:

1. Odznaczyć Just My Code.
2. Zaznaczyć Enable .NET Framework source stepping.
3. Zaznaczyć Enable source server support.
4. Odznaczyć Require source files to exactly match the original version.

Powinno to wyglądać jak na poniższym obrazku:

Debugowanie kodu zewnętrznego (czyli np. paczek NuGeta)

Tu procedura jest nieco bardziej skomplikowana

1. Uruchamiamy dotPeeka.
2. Z menu File wybieramy Open.
3. Odszukujemy na dysku plik(i) dll interesującej nas biblioteki. W przypadku paczki NuGeta z ASP.NET MVC będzie to katalog packages\Microsoft.AspNet.Mvc.5.2.3\lib\net45. Okno aplikacji powinno wyglądać tak:
4. Z menu Tools wybieramy pozycje Options a następnie Symbol Server. Zaznaczamy tam pozycję Assemblies opened in the Assembly Explorer. Możemy też zmienić numer portu, jeśli domyślny nam nie odpowiada. Okno ustawień wygląda tak:
5. Wybieramy Tools -> Symbols Server, aby wystartować serwer symboli. Upewniamy się, że czerwony kwadracik na przycisku zmienił się w zielony trójkącik. :)
6. Teraz wracamy do Visual Studio i uruchamiamy Tools -> Options -> Debugging -> Symbols. Tam klikamy przycisk dodawania nowego źródła symboli (zaznaczony na poniższym obrazku ramką) i wpisujemy http://localhost:33417/ (albo inny port skonfigurowany dla dotPeeka). Podajemy też ścieżkę dla Cache symbols in this directory: Efekt ma wyglądać tak:
7. Teraz już możemy zaczynać debugowanie. Po uruchomieniu aplikacji w trybie debugowania, Visual Studio zacznie ściągać symbole z Microsoftu oraz z dotPeeka. dotPeek w trakcie pracy będzie wyglądał tak: Żółte ikonki ostrzeżeń oznaczają, że tych plików nie było w Assembly Explorerze, więc zgodnie z ustawieniami nie są generowane.

Uwagi końcowe

1. Pierwsze uruchomienie aplikacji w trybie debug może potrwać dość długo. Pobieranie i generowanie symboli trwa pewien czas, nie należy się niepokoić nawet, jeśli będzie to kilkanaście minut.
2. Nie daję żadnej gwarancji, że to zadziała. Mi się udało to wszystko uruchomić i zgrać ze sobą dopiero po kilkunastu próbach.
3. Po tym, jak Visual Studio zapisze sobie symbole do cachu, następnym razem nie musimy uruchamiać dotPeeka. (Oczywiście dopóki nie będziemy chcieli debugować innych bibliotek.)