Dziś biorę na tapet dwa najpopularniejsze IDE dla .NET developerów – Visual Studio i JetBrains Rider. Czym się różnią? I dlaczego używam już (prawie) tylko Ridera? 😉
Szybkość działania
Głównym i wystarczającym powodem do przesiadki na Ridera jest szybkość działania. Jeśli korzystasz z Visual Studio z ReSharperem, różnica będzie ogromna. Rider dostarcza te same funkcjonalności co wtyczka JetBrainsa do VS i wiele więcej, a działa przy tym X razy szybciej. Nie znam dokładnych statystyk, ale gwarantuję, że momentalnie poczujesz ogromną różnicę.
Śmiem twierdzić, że Visual Studio nawet bez ReSharpera działa wolniej niż Rider. Polecam po prostu spróbować. Ja od ponad roku nie wracam już do VS (prawie – ale o tym w dalszej części).
Wyszukiwanie
Wyszukiwanie w Riderze to bajka. Pierwszym przydatnym skrótem klawiszowym jest Ctrl+T, który otwiera okno wyszukiwania:
Można osobno szukać klas, plików czy symboli (np. pól w klasach). IDE zapamiętuje też ostatnio wyszukiwane elementy i prezentuje je na górze listy. Super to działa.
Kolejnym trybem, którego bardzo często używam, jest wyszukiwanie tekstowe w plikach (Crtl+Shift+F):
Jest to bardzo przydatne, jeśli potrzebujemy znaleźć w całej solucji wybrany tekst, np. tłumaczenie albo treść wiadomości z błędem, który widnieje w zgłoszeniu od klienta. W dolnej części okna dostajemy od razu podgląd odpowiedniego fragmentu pliku.
Wyszukiwanie tekstowe można zawęzić do solucji, projektu, katalogu albo scope.
Zawsze brakowało mi takiego „dynamicznego” wyszukiwania tekstów w Visual Studio. ReSharper trochę pomagał funkcją search everywhere, ale nie działało to tak dobrze i naturalnie jak w konkurencyjnym IDE od JetBrains.
Synchronizacja ustawień
Wiele ustawień IDE, w tym wielkość czcionki, ustawienia edytora i wtyczki, można synchronizować z kontem JetBrains:
Przez długi czas nie było takiej opcji w Visual Studio, chociaż czytam, że ponoć też już jest. Nie wiem jednak jak działa w praktyce 😉
Tooling do testów
Bardzo lubię tooling do testów w Riderze. Jeśli aktywujemy plugin dotCover, dostajemy wiele ciekawych dodatków, między innymi continuous testing. Pozwala to na uruchomienie wybranego zestawu testów w momencie zapisu pliku po zmianach w kodzie albo po każdym lokalnym buildzie. Bardzo przydatne gdy stosujemy TDD albo refactorujemy kod.
Bardzo spoko działa też code coverage:
W Visual Studio oczywiście również da się to osiągnąć korzystając z rozszerzenia dotCover, ale tutaj jest to bardziej naturalne. No i oczywiście działa szybciej 😉
Konfiguracje buildowania
Super ficzerem Ridera jest też możliwość szerokiej konfiguracji customowych buildów i uruchamiania. Jest to przydatne, gdy pracujesz ze złożonym systemem i po buildzie chcesz np. odpalić jakiś skrypt, potem jakąś aplikację, później kolejny skrypt itd.
Build buduje się na zasadzie kroków, które mogą być w zasadzie czymkolwiek:
Po całym procesie Rider może też uruchomić przeglądarkę internetową na wskazanym URLu, nawet z podpiętym debuggerem JS 😉
Problemy Ridera
Ale czy Rider jest taki idealny? No, prawie 😉
Jedyna rzecz, którą nadal robię w Visual Studio, to przebudowywanie T4MVC w projekcie ASP.NET MVC 5. Tego IDE od JetBrains jeszcze nie ogarnia.
Poza tym, dla nowego użytkownika Ridera debugowanie może wydawać się nieintuicyjne. Mnie i kolegów z zespołu od początku denerwowało, że Rider często z automatu „wchodził” w trybie debugowania w kod zewnętrznych bibliotek.
Drugi problem był z wyjątkami. Dostajesz zgłoszenie błędu. W scenariuszu A leci wyjątek X. Odpalasz więc apkę w trybie Debug, powtarzasz scenariusz A i oczekujesz, że IDE „zatrzyma” się w miejscu rzucenia wyjątku X. A tu niespodzianka – Rider stawia breakpoint gdzieś w bibliotekach .NETa 🤯 Albo w innym, zupełnie „z dupy” miejscu.
Żeby uniknąć tych problemów, polecam skonfigurowanie Ridera w następujący sposób:
Czyli wyłączamy opcję „Enable external source debug” i włączamy „Break on user-unhandled exceptions (.NET/.NET Core only)”.
Jeśli w Twojej sytuacji debugger nadal nie zatrzymuje się poprawnie na rzucanych wyjątkach, możesz pomyśleć o dorzuceniu wszystkich możliwych wyjątków w oknie Run -> Stop On Exception:
Efektem będzie zatrzymywanie się przez debugger w miejscu rzucenia każdego z wybranych wyjątków. Na początku mogą to być wyjątki frameworka czy inne, co może Cię wkurzać. Na szczęście w momencie zatrzymania debuggera na takim wyjątku jest możliwość zignorowania go, co usunie go z powyższej listy. Po jakimś czasie działania w ten sposób na liście wyjątków pozostaną już tylko te, które Cię interesują 😉
Podsumowanie
Jeszcze raz na koniec – dla mnie Rider jest genialnym IDE i absolutnie gniecie Visual Studio. Nawet jeśli Twój pracodawca nie finansuje licencji na Ridera, cena $149 za rok (za pakiet dotUltimate) nie wydaje się bardzo wygórowana. Tym bardziej że można to wrzucić w koszty prowadzenia firmy 😉
A jak jest u Ciebie? Rider czy VS? 🙂
Używam od roku i nie planuję powrotu do VS. Jak ktoś nie chce płacić można spróbować EAP jetbrains.com/rider/nextversion/
Hej Adam,
dzięki za info o EAP – nie znałem 😉 W sumie fajna opcja, jak ktoś nie chce wydawać od razu hajsu. A wiesz, jak to w praktyce wygląda z wersją EAP? W miarę stabilnie? 😉
Czy Rider daje już możliwość odpinania okien i przenoszenia na inny monitor, jak VS czy dalej można mieć tylko jedno (główne) okno?
Hej Piotr,
ja jestem na jednym ekranie laptopowym od 2 lat 😂, ale koledzy z zespołu mówią, że można przenosić okna między monitorami 😉
Mozna prosic o artykul z twojego TDD z GildedRose?
Siema Leszek,
GildedRose robiłem w ramach kursu AntiIF z Arkademy (http://arkademy.dev/) i bardzo polecam 😉 Jak chcesz zerknąć to kod jest tutaj: https://github.com/dsibinski/anti-if-gilded-rose-csharp
Może kiedyś napiszę też jakiegoś posta 🙂
Dodałbym przede wszystkim, że Rider jest 64 bitowy a VS wciąż 32. To jest duży plus na korzyść Ridera.
Siema Grzegorz,
no tak, to jest główny powód przewagi wydajnościowej Ridera nad VS. 32-bitowe Visual Studio to jednak gruba sprawa i raczej nie zapowiada się, żeby miało się to zmienić 😉 No i tutaj VS sporo traci.
Korzystałeś może z VS 2022 i jeśli tak, to jak wygląda sprawa wydajności z porównaniu z Riderem? Planujesz wrócić do VS czy już Rider forever? 😉
Korzystałem ostatnio przez 2 dni, z ReSharperem w wersji beta wspierającej VS2022. Jest dużo lepiej niż wcześniej, ale dla mnie nadal działa to wolniej niż Rider 😉 Mam wrażenie, że odpalanie niektórych funkcji czy klikanie po zakładkach nadal powoduje jakiegoś 0.5-sekundowego laga.
Długo trwa ładowanie solucji ze wszystkimi ficzerami R#, ale nie jest to duży problem.
Szczerze mówiąc, na tyle przywykłem już do Ridera, że nie widzę powodów powrotu do VS. Aktualnie to takie „sprawdzanie, czy VS już dorównało Riderowi”. Visual Studio musiałoby mnie przekonać czymś wyjątkowym, a póki co tak nie jest 😉 Używanie VS dla używania VS jakoś do mnie nie przemawia.