Wprowadzenie

W kolejnym wpisie pozostajemy przy zmianach, które pojawiły się w nowej wersji Visual Studio 2019. Tym razem zajmiemy się zmianami w debugowaniu aplikacji. Pojawiło się kilka ciekawych rzeczy, takich jak wyszukiwanie w okienkach Autos, Locals, Watch, Data Breakpoint czy zwiększenie wydajności. Jeśli jeszcze nie pobrałeś/pobrałaś Visual Studio 2019, to gorąco zachęcam, bo warto!

Zwiększona wydajność

Po zainstalowaniu i uruchomieniu Visual Studio 2019 można zauważyć, że nowa wersja działa szybciej. Microsoft położył spory nacisk na to, aby nowa wersja działała szybciej. Widać to w różnych miejscach, również podczas debugowania aplikacji.

Po pierwsze większość okien w Visual Studio (takich jak Watch, Call Stack itp.) jest teraz asynchroniczna, co powoduje, że są bardziej responsywne niż we wcześniejszych wersjach. Po drugie został również zredukowany czas aktualizacji interfejsu tych okien o około 70%, co też przekłada się na szybszą pracę.

Dodatkowo przechodzenie linia po linii podczas debugowania (skrót F10) również zostało przyśpieszone o około połowę.

Dodatkowo twórcy dużych aplikacji w C++ (takich jak na przykład gry) wiele zyskają dzięki nowej wersji. W przypadku debugowania takich dużych aplikacji bardzo mocno (o 84%) zostało zredukowane wykorzystanie pamięci, przez co można znacznie dłużej debugować aplikację bez wyjątku OutOfMemory.

Oczywiście wszystkie liczby są podane przez Microsoft i, jak to bywa w takich przypadkach, trzeba by podejść do tego z rezerwą. Ale z drugiej strony, pracując z Visual Studio 2019, wyraźnie czuć, że jest szybciej.

Filtrowanie w oknach Locals, Autos, Watch

Pierwszą z nowych funkcjonalności, jaką będę chciał Ci pokazać w tym wpisie, jest filtrowanie w oknach Locals, Autos, Watch.

Zapewne nie raz miałeś/miałaś tak, że wręcz godzinami szukałeś/szukałaś jakiegoś obiektu/właściwości na przykład w okienku Autos, rozwijając wszystko, co można, tak jak to widać poniżej w Visual Studio 2017:

Oczywiście po wykonaniu się fragmentu kodu i zatrzymaniu w kolejnym breakpoincie musimy powtórzyć całą czynność.

Na szczęście Microsoft w Visual Studio 2019 w tych oknach udostępnił możliwość wyszukiwania. Co fajne, możemy wyszukiwać po nazwach właściwości, pól, ale również i po samych wartościach:

W górnej części okna pojawił się textbox, w którym możemy wpisać interesującą nas wartość. Tak jak widać powyżej, w trakcie wpisywania wartości Visual Studio podświetla znalezione elementy – w tym przypadku nazwę właściwości oraz wartość innej właściwości. To bardzo ułatwia korzystanie z okien tego typu.

Dodatkowo obok textboxa znajduje się combobox, w którym określamy poziom zagłębienia, do jakiego Visual Studio wyszukuje wartości. To się przydaje wtedy, gdy obiekty mają same do siebie referencje (np. jak to jest z relacjami w obiektach pobranych dzięki Entity Framework).

Już kilka dni korzystam z tego filtrowania i muszę przyznać, że sprawdza się bardzo fajnie. Teraz nie chciałbym wrócić do Visual Studio 2017, gdzie musiałbym ręcznie wyszukiwać obiekty. 🙂

Data Breakpoint

Kolejną ciekawą funkcjonalnością dodaną do Visual Studio 2019 jest Data Breakpoint. Funkcjonalność ta jest znana programistom C++ w Visual Studio od dawna. Natomiast my, programiści C#, musieliśmy (a tak naprawdę jeszcze musimy) trochę poczekać.

Data Breakpoint to taki typ przerwania, w którym definiujemy, że debugger ma się zatrzymać w momencie zmiany wartości pola lub właściwości. Wcześniej obchodziliśmy ten problem, stawiając breakpointa w setterze, ale działało to tylko w kodzie, do którego mieliśmy dostęp. Teraz możemy to zrobić również dla kodu biblioteki, której używamy.

Aby postawić Data Breakpoint, musimy najpierw zatrzymać się innym typem breakpointa w miejscu, gdzie mamy dostęp do interesującego nas obiektu. Następnie na przykład w oknie Autos klikamy prawym klawiszem myszy na interesującą nas właściwość/pole i wybieramy „Break When Value Changes”:

Na powyższym zrzucie ekranu wykonuję to dla właściwości Count klasy List<User>. Dzięki temu Visual Studio zatrzyma mi się w momencie, gdy aplikacja wykona jakąś operację na liście, która zmienia jej liczebność. Dodatkowo warto zauważyć, że breakpointa stawiam na obiekcie, do którego kodu normalnie nie mam dostępu i nie mogę w setterze ustawić zwykłego breakpointa.

Po ustawieniu Data Breakpoint dane pole lub właściwość są oznaczone czerwonym kółkiem breakpointa. Do tego sam obiekt ma ustawione id (w tym przypadku $1). W tym momencie możemy również odwoływać się do obiektu za pomocą tego id. Nawet w sytuacji, gdy nie znajduje się on w ramach danego zasięgu (debugger zatrzymał się w zupełnie innym miejscu kodu).

W momencie gdy nastąpiła zmiana wartości, Visual Studio zatrzyma się w danym miejscu oraz pokaże okienko z informacją o zmianie wartości:

Na powyższym zrzucie widać, że kod zatrzymał się na wywołaniu metody Add klasy List. Visual Studio 2019 pokazało okno, w którym widzimy między innymi starą oraz nową wartość.

Data Breakpoint są bardzo przydatne. W tym momencie mają jednak pewne ograniczenie. Działają tylko dla .NET Core 3.0, ale z tego, co widziałem, planują również z czasem dodać je do wcześniejszych wersji oraz pełnego .NET.

Podsumowanie

Microsoft nie dodał zbyt wiele zmian, które przydadzą się podczas debugowania aplikacji. Jednak te, które się pojawiły, raczej spodobają się każdemu i ułatwią codzienną pracę. Zwłaszcza gdy Microsoft doda wsparcie dla Data Breakpoint również dla pozostałych wersji .NET.

W Visual Studio 2019 Enterprise pojawiła się jeszcze jedna nowość związana z debugowaniem aplikacji w Azure. Jest nią Time Travel Debugging, który jest rozbudowaniem Snapshot Debuggera z Visual Studio 2017. Ale oba te narzędzia to temat na zupełnie inny wpis, który pojawi się w ciągu kilku następnych tygodni.

Zachęcam do przeczytania innych wpisów o Visual Studio 2019 – Live Share oraz IntelliCode.