Wprowadzenie

Zapewne nie raz miałeś(-łaś) tak, że aplikacja na produkcji, u klienta lub serwerze testowym działa inaczej, niż powinna. A to pojawia się jakiś wyjątek, a to wynik operacji jest inny, niż powinien być. Znając życie, w logach nic ciekawego nie było i przez dłuższy czas dodawałeś(-łaś) do nich kolejne linijki w pogoni za błędem. Myślę, że każdy z nas miał wcześniej czy później podobny problem.

Nie raz przemknęło Ci przez myśl, by zainstalować Visual Studio, aby zdebugować problem, w szczególności gdy Remote Debugger nie działał. Na szczęście mamy inną opcje, którą można wykorzystać. Jest nią darmowa aplikacja dnSpy, o której w dzisiejszym wpisie.

dnSpy

dnSpy (https://github.com/0xd4d/dnSpy) jest jednym z narzędzi, które warto znać, bo bardzo przydaje się w różnych sytuacjach (między innymi w tej opisanej we wstępie).

Po pierwsze, umożliwia zdekompilowanie kodu. Pod spodem wykorzystuje ILSpy, za pomocą którego możemy zobaczyć kod aplikacji. dnSpy nawet ładnie koloruje składnię:

Powyżej znajduje się zdekompilowany kod testowej aplikacji WPF z wpisu o walidacji danych z wykorzystaniem Fluent Validation w WPF. Oczywiście kod jest trochę inny niż ten, z którego aplikacja została skompilowana, ale na ogół nie ma większego problemu z jego zrozumieniem i analizą. Poniżej znajduje się kod viewmodelu z powyższego zrzutu ekranu:

W przypadku używania jakiegoś zaciemniania kodu jego analiza w dnSpy na ogół jest niemożliwa.

Debugowanie aplikacji

Po drugie, możemy debugować aplikację. Myślę, że jest to najfajniejszą opcją w dnSpy, z której wielokrotnie korzystałem. Nie potrzebujemy dostępu do kodu aplikacji, a ponadto możemy wykonać go sobie linijka po linijce, podobnie jak w Visual Studio. Możemy uruchomić nowy proces aplikacji lub podpiąć się pod istniejący (np. proces w3p). Dodatkowo domyślne skróty są takie same jak w Visual Studio:

Normalnie stawiamy breakpointy, a następnie wykonujemy kod linijka po linijce. Również tutaj skróty klawiszowe są takie same jak w Visual Studio (nie znasz tych skrótów? Zapraszam do mojego darmowego kursu o Visual Studio). Na dole znajduje się okienko Locals z wartościami obiektów, zmiennych, parametrów:

Debugowanie aplikacji w dnSpy jest dużo mniej rozbudowane niż w Visual Studio. Na tyle jednak wystarczające, że spokojnie możemy znaleźć problem dużo sprawniej i efektywniej, niż korzystając z wybrakowanych logów.

Oczywiście musimy pamiętać, że w przypadku debugowania produkcji cała aplikacja zostaje zatrzymana, co prawdopodobnie w większości przypadków jest niedopuszczalne. Wtedy trzeba skorzystać z jakiegoś innego mechanizmu do szukania błędu w aplikacji.

Co jeszcze?

dnSpy ma jeszcze kilka innych funkcjonalności, które mogą Ci się przydać, choć ja z nich korzystam dużo rzadziej.

Możesz między innymi modyfikować kod assembly – na przykład zmieniać lub dodawać klasy, metody, właściwości itd.; również z prostym wsparciem Intellisense. Może się to przydać w sytuacji, gdy wdrożona wersja aplikacji ma jakiś głupi błąd (np. wywołujesz jakąś metodę z błędną wartością parametru). Zamiast wdrożyć całą aplikacje od nowa, co może trwać dłuższą chwilkę, możesz na szybko poprawić ten błąd w dnSpy i poczekać do nocy, gdy aplikacja jest mnie obciążona, z wrzuceniem poprawionej wersji.

Podobnie można to wykorzystać do szukania rozwiązania problemu. Zamiast zmieniać kod w Visual Studio i wrzucać go na serwer testowy, możesz na serwerze zmieniać kod do momentu znalezienia rozwiązania i dopiero później przenieść rozwiązanie do Visual Studio.

Lista wszystkich funkcjonalności dnSpy jest ładnie rozpisana na githubie projektu. Zachęcam do jej przejrzenia: https://github.com/0xd4d/dnSpy

Podsumowanie

dnSpy jest aplikacją, którą jako programista .NET powinieneś znać. W niektórych sytuacjach może znacznie ułatwić szukanie błędu w aplikacji, zwłaszcza w środowisku, w którym nie masz dostępu do Visual Studio. Dekompilacja kodu oraz możliwość jego debugowania bardzo się przydaje. A do tego jest możliwość zmiany kodu, która powoduje, że jesteś w stanie szybko naprawić jakiś problem bez konieczności czasochłonnego wdrażania nowej wersji aplikacji.

A możesz znasz jakieś inne tego typu narzędzie, które każdy programista .NET powinien znać? Podziel się nim w komentarzu!