Czasami zdarzają się sytuacje, że pomimo usilnych prób nie możemy zreprodukować błędu u siebie na maszynie lokalnej. Musimy sprawdzić dlaczego nasza aplikacji źle działa na maszynie produkcyjnej. W tym wpisie postaram się przedstawić jakie narzędzia mamy do dyspozycji jeśli jeśli taka potrzeba zajdzie. Zobaczmy co jest zatem dostępne.

Visual Studio Remote Debugging

remote debuggingPierwszą naszą opcją jest Remote debugging dostępny w VisualStudio. Wraz z zainstalowanym VS instalują nam się komponenty, które możemy wykorzystać do zdalnego podłączenia się z serwerem i uruchomienia aplikacji właśnie tam; podczas, gdy pułapki i zmienne możemy sobie oglądać w naszym lokalnym VisualStudio. Jak to zrobić? Przede wszystkim na maszynie zdalnej musimy uruchomić Visual Studio Remote Debugging Monitor. Jest to małe narzędzie, które będzie monitorować przychodzące zdalne sesje debuggowania i nimi zarządzać.
vsrdm
Następnie możemy, albo uruchomić aplikację z naszego VS zdalnie albo też podpiąć się do już działającego procesu na maszynie. Zobaczmy jak skonfigurować to pierwsze. Uruchamiamy projekt naszej aplikacji i przechodzimy do właściwości. Na karcie debug wypełniamy odpowiednio. Zaznaczamy opcję Start external program i wprowadzamy ścieżkę do naszej aplikacji – taką, jaka jest na zdalnej maszynie! Następnie zaznaczamy opcję Use remote machine i wprowadzamy nazwę serwera, którą podał nam Remote Debugging Monitor. Zapisujemy ustawienia i uruchamiamy naszą aplikację. W czasie uruchamiania możemy jeszcze otrzymać komunikat o cache’owaniu symboli na zdalnej maszynie i być może będziemy musili zmodyfikować ustawienia w Option->Debugging->Symbols. Po zapoznaniu się z tą informacją nasza aplikacja jest uruchamiana na zdalnej maszynie a breakpointy, podgląd zmiennych i wszystko inne co związane z debuggowaniem widzimy w naszym lokalnym VS. Dla przykładu porównanie tego co zwraca Environment.MachineName z nazwą komputera w systemie.
p01
Druga opcja, tak jak już wspomniałem wcześniej, to podłączenie się do działającego już procesu na maszynie zdalnej. W tym celu otwieramy okno ‘Debug – Attach’ a następnie w polu Qualifier wpisujemy nazwę serwera sesji zdalnego debuggowania czyli w moim przypadku pawlos@PAWLOS-LAPTOP i po odświeżeniu listy procesów możemy podpiąć się do naszego procesu uruchomionego na zdalnej maszynie. Dalej już podobnie jak w przypadku poprzednim, działamy tak jakbyś debuggowali naszą aplikację lokalnie.

Plus? Minusy?

Jakie korzyści płyną z takiego rozwiązania? Przede wszystkim pozostajemy w VS, które większość z nas zna dość dobrze. Dzięki temu nie trzeba poznawać nowych narzędzi (choć to czasem minus), aby rozpoznać dlaczego nasza aplikacja nie działa. Plusem jest też, iż pomimo tego, że Visual Studio Remote Debugging Monitor jest instalowany razem z Visual Studio to możemy go nagrać na pendrive’a i mieć go ze sobą zawsze (ja mam na swoim zestawie niezbędnych aplikacji). Wady? Problemy z firewallem w Windows, który blokuje połączenia pomiędzy maszynami co czasem może skutecznie uniemożliwić skorzystanie z tego rozwiązania. Czy wtedy pozostajemy bez wyjścia? Nie. W następnej części zobaczymy co oferuje nam mDbg.
Miłego debuggowania.