Wstęp

Zazwyczaj tego nie robię. Gdy wychodzi nowy Visual, zazwyczaj czekam około pół roku zanim go zainstaluję i zacznę używać. Po prostu chcę uniknąć głupich problemów „wieku dziecięcego”. Tym razem jednak było inaczej. Z jakiegoś powodu nie mogłem doczekać się Visual Studio 2022. Zainstalowałem sobie nawet wersję Preview, ale w sumie nie używałem jej. W końcu wyszło… Poczułem silną wewnętrzną potrzebę przetestowania tego ustrojstwa i jak najszybszego używania go… W tym artykule dzielę się swoimi pierwszymi spostrzeżeniami. Opisuję wersję 17.0.0 Community

Sprzęt

Być może sprzęt, na którym go testuje ma jakieś znaczenie (na pewno ma w pewnych sytuacjach), dlatego postanowiłem przedstawić Wam go

• Sprzęt: HP Pro Book 450 G3
• System operacyjny: Windows 10 19042
• Procesor: Intel Core i3-6100U 2.30 GHz, 2 rdzenie, 4 logiczne procesory
• RAM: 16 GB
• Ekran 17″

Testowałem też na innym kompie – 2 spore monitory (z czego jeden 4K) i 16 rdzeni (dokładnej konfiguracji nie pamiętam)

Instalacja

Tutaj nie ma nowości. Pobrany instalator musiał najpierw ściągnąć kilka rzeczy, co zajęło mu około 30 sekund. Następnie uruchomił się już znany Visual Studio Installer, w którym wybrałem takie składniki:

• ASP.NET Core, ASP.NET
• Node.js
• Aplikacje mobilne (Xamarin)
• Programowanie aplikacji klasycznych .NET
• Magazynowanie i przetwarzanie danych
• Programowanie rozszerzeń Visual Studio

Niektóre „podskładniki” jak np. środowisko uruchomieniowe .NET 5 miałem już zainstalowane, więc czas instalacji będzie nieco krótszy.

W każdym razie, wszystko zajęło 11,12 GB. A całkowity czas instalacji to około 11 minut. Całkiem nieźle, biorąc pod uwagę, że AKTUALIZACJA VS2019 z wersji 16.11.5 na 16.11.6 zajęła prawie 7 i pół minuty.

Otwieranie solucji

Widziałem jak MS chwalił się szybkością otwierania solucji z ponad 100 projektami. Na pokazie trwało to naprawdę szybko. Żeby niczego nie zaburzyć, postanowiłem pierwsze otwarcie przeprowadzić bez żadnego kodu. Podejrzewam, że podczas pierwszego uruchamiania VS robi więcej rzeczy niż zazwyczaj.

Otwarcie solucji z 36 projektami trwało 50 sekund. Przy czym otwarcie tej samej solucji na VS2019 trwało 45 sekund. ALE! Najwidoczniej VS2022 optymalizuje sobie w jakiś sposób pracę. Drugie otwarcie tej samej solucji w VS2022 (po restarcie środowiska) zajęło już tylko 30 sekund. Więc faktycznie coś w tym jest.

Wygląd

Wygląd różni się nieco od VS2019. Są inne ikonki, inne czcionki… Wszystko to ponoć ma sprawić przyjemniejszą i bardziej skupioną pracę. Myślę, że ocena tego jest dość indywidualna, a ja jeszcze nie spędziłem przy tym środowisku tyle czasu, żeby móc to ocenić.

Co się jednak rzuca w oczy na początek, to czcionka w edytorze kodu. I tu mam mieszane uczucia. Na dużym monitorze 4K wygląda to całkiem nieźle. Natomiast na moim laptopie z ekranem 17″… było mi jakby za ciasno. Dlatego zmieniłem na starą Consolas. Ale to też kwestia dość indywidualna.

Pierwszy problem…

Na jednym komputerze wszystko poszło podejrzanie sprawnie. Jednak na drugim nie mogłem uruchomić aplikacji .NetCore WPF w środowisku. Ciągle dostawałem błąd:

The target process exited without raising a CoreCLR started event.Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core

Przeszukałem Internety wzdłuż i wszerz i dupa. Restarty, reinstalacje .NetCore, odinstalowywanie starszych wersji… nic nie dawało rady. Wygląda na to, że podczas pierwszej instalacji czegoś nie dopatrzyłem, co było potrzebne dla mojej aplikacji. Gdy doinstalowałem kilka rzeczy później nadal nic nie działało. Musiałem ostatecznie wybrać opcję „Napraw” z VsInstallera. I wtedy wszystko zaczęło magicznie działać.

Z czego wynika ten problem? W pierwszej wersji VS2019 był to faktycznie jakiś problem ze środowiskiem. Tutaj ciężko mi powiedzieć. Być może środowisko nie ogarnęło czegoś w 100% podczas doinstalowywania modułów.

Hot Reload

Podczas prezentacji niesamowicie jarali się mechanizmem HotReload, który ponoć w tej wersji jest przełomowy. I faktycznie – pokazywali Hot Reload w projekcie w C++, co mnie zupełnie zbiło z tropu. Postanowiłem to sprawdzić na jakimś projekcie MFC…

C++ i MFC

No niestety. Wygląda na to, że MFC jest zbyt starą technologią, żeby wspierało HotReload. Niestety można się było tego spodziewać. Więcej nie testuję C++, chociaż na prezentacji faktycznie to działało (oczywiście nie pokazywali tego na MFC, tylko na jakiejś prostej gierce).

WPF

Na pierwszy rzut oka naprawdę bardzo fajnie to działa. Można robić zmiany zarówno w XAML jak i w kodzie C# (!) i HotReload naprawdę daje radę. Co więcej, nie trzeba nawet zapisywać tych zmian! Wszystko dzieje się na bieżąco. Można zmieniać nawet style, a także user controlsy, co kiedyś było upierdliwe i to działa… ale… no właśnie.

Podczas zmian w globalnych stylach w pliku App.xaml coś się pieprzy i zmiany nie są widoczne. Co więcej, cała aplikacja jakby znalazła się w jakimś dziwnym stanie zawieszenia. Chociaż MS sam mówił, że przy niektórych zmianach w kodzie trzeba jednak zrestartować aplikację. Może ma to jakiś związek.

Co więcej, świetne jest okienko Preview (Debug -> Windows -> XAML Live Preview). Pokazuje aktualne okno uruchomionej aplikacji. Świetnie się sprawdza w przypadku jednego monitora, bo nie trzeba przełączać się między Visualem i aplikacją. Okienko Preview jest po prostu zadokowane. Zmiany są widoczne zarówno w tym oknie, jak i w aplikacji. Okienko preview ma też kilka dodatkowych rzeczy w stylu linijek znanych z programów graficznych. Bardzo to może wspomóc ustawianie elementów.

Dodatkowo jest w stanie pokazać w jakim pliku znajduje się jak element:

Ogólne wrażenie: PLUS. Gdyby nie ten problem z plikiem App.xaml, byłbym niesamowicie zachwycony. Ale nadal – czapki z głów. Naprawdę dobrze działający mechanizm.

Xamarin

HotReload w Xamarinie zazwyczaj działało mi „od święta”. Głównie jednak nie działało, co było bardzo frustrujące i zabierało mnóstwo czasu. Dlatego z wielkim polskim przekąsem na twarzy podszedłem do tego tematu…

No cóż… Dupy nie urywa. HotReload w Xamarinie „potrafi” działać w dwóch trybach (od pewnej wersji). Może odświeżać tylko to, co się zmieniło lub całą stronę.

Okienko Preview udało mi się pokazać tylko w trybie „odświeżania samych zmian”. Natomiast w trybie odświeżania całej strony w ogóle nie działało. Ale to nie jest najgorsze. Tryb odświeżania tylko zmian w ogóle nie chciał działać. Udało się za to uruchomić HotReload w trybie odświeżania całej strony. Nie działa to jednak tak super jak w WPF. Tutaj jest jeszcze trochę pracy do zrobienia.

Jednak, podczas moich testów, HotReload w trybie odświeżania całego ekranu działał cały czas.

Ogólne wrażenie: mieszane… bardziej negatywne. Coś tam działa. Ale kiedy przestanie?

ASP.NET MVC

Niestety tutaj nie działa. Ale MS pisze o tym na swoich stronach. Więc tutaj trzeba posługiwać się starymi metodami. Podobnie jak…

BLAZOR!

Technologia, w której ostatnio się podkochuję. Obiecali, k… obiecali! Obiecali, że będzie Hot Reload! No i jest… Podobno. Gdy używa się .NET6. Aplikacja w Blazor, którą gdzieś tam sobie robię na boku jest na .NET5 i ma dla mnie aktualnie dość niski priorytet. W końcu zmigruję ją do .NET6 i wtedy sprawdzę. Póki co… Smutek…

Designer

Tutaj właściwie napiszę tylko o WPF. W Xamarinie standardowo nie ma takiego pojęcia jak designer, w corowych aplikacjach webowych też nie. Designer w WinForms właściwie się nie zmienił, dlatego opisuję to dla WPF.

Designer w WPF zyskał kilka nowych i fajnych elementów. Przede wszystkim można zmienić niektóre właściwości kontrolki, zaznaczając ją, a następnie klikając żaróweczkę, która się pojawia:

Może i pierdoła, ale naprawdę ułatwia życie.

Ale największy życioułatwiacz dla mnie to element „d” w XAML. Na pewno nie raz miałeś taką sytuację, że musiałeś zaprojektować jakiś element znajdujący się na jakiejś liście. I co wtedy się robi? Trzeba stworzyć jakieś fake’owe dane, żeby elementy były widoczne na liście w design time i generalnie potem trzeba pamiętać, żeby powrócić do prawdziwych danych… Nie jest to zbyt eleganckie rozwiązanie.

Tutaj mamy coś takiego jak wersja w design time (stąd „d”). Kod powie więcej niż 1000 słów:

<TextBlock Text="{Binding Name}" 
           d:Text="Nazwa elementu"
           FontWeight="{Binding Modified, Converter={StaticResource BoolToFontWeight}}"
           d:FontWeight="Bold"/>

Jak widzisz mamy tutaj właściwości Text i d:Text. FontWeight i d:FontWeight. Te prawdziwe właściwości (Text i FontWeight) działają normalnie – w runtime, czyli gdy aplikacja jest uruchomiona. Jeśli jednak jesteś w design time (aplikacja jest projektowana), działają właściwości z elementem d:. Czyli wszystko, co ma d: zostanie użyte w czasie projektowania aplikacji. Dla mnie jest to niesamowita opcja.

Wyszukiwanie plików

Zawsze niesamowicie denerwowało mnie wyszukiwanie plików w solution explorerze. Działało to bardzo topornie, a czasami pokazywało strasznie długą listę, na której trzeba było znaleźć to, co się chce. Właściwie pozostawało używanie thirdparty pluginów…

W wersji 2022 wreszcie działa to lepiej. Szukanie jest zdecydowanie szybsze i pokazuje wyniki, które bardziej pasują do tego, co chcesz znaleźć.

Podpowiedzi w kodzie – sztuczna inteligencja

Nie mówię tutaj o Intellisense. W tej wersji wprowadzili sztuczną inteligencję, która podpowiada Ci, co powinieneś napisać. Niedługo dojdzie do tego, że będziemy programować wciskając tylko tabulator 😉

Działa to tak, że Microsoft przeanalizował mnóstwo kodów, przede wszystkim na GitHubie i na tej podstawie nauczył sieć neuronową… programowania. To oczywiście zbyt duże słowo. Ale faktycznie – sztuczna inteligencja w jakiś sposób rozpoznaje kontekst w jakim się znajduje i w jakiś szatański sposób potrafi przewidzieć, co chcesz napisać. Testowałem to na swoich kodach. W miejscach, gdzie klasy były raczej unikalne i konteksty raczej też. No nie były to miejsca „typowe”. I ku mojemu wielkiemu zdziwieniu – działa całkiem nieźle. I nawet nie przeszkadza.

To co widzisz na obrazku powyżej to oczywiście dość „typowe” miejsce, ale wierz mi, że mechanizm jest naprawdę ciekawy. Podczas moich testów kilka razy naprawdę mnie zaskoczył.

MAUI

A gdzie MAUI? Cytują klasyka: „W d… bede grał w gre”. Na obietnicach się skończyło. Chłopaki i dziewczyny nie wyrobili się z MAUI na tą wersję, chociaż można już testować PREVIEW. Jest szansa, że w wersji produkcyjnej pojawi się w przeciągu 6 miesięcy.

To na razie tyle z mojego pierwszego spojrzenia. Mimo to, że VS2022 jest jeszcze gorący jak bułki z piekarni, to jednak warto go zainstalować i używać. Jestem naprawdę pozytywnie zaskoczony. Wersję Community możesz pobrać stąd: https://visualstudio.microsoft.com/pl/thank-you-downloading-visual-studio/?sku=Community&rel=17

A Ty zainstalowałeś już VS2022? Jakie są Twoje spostrzeżenia? Podziel się w komentarzu.