Wprowadzenie

W poprzednim wpisie pokazałem jakiej konfiguracji, a dokładnie jakich rozszerzeń Visual Studio Code używam na co dzień tworząc aplikacje w .NET na Linux Mint. W tym wpisie pokażę kilka dodatkowych rozszerzeń do VS Code z których korzystam na co dzień i które pomagają mi w codziennej pracy. 

Thunder Client

Pierwszą z takich dodatkowych wtyczek jest Thunder Client. Bardzo prosty klient API, który jest uproszczoną wersją Postmana czy Insomni. Pozwala nam wykonywać podstawowe czynności związane z pracą z API takie jak: 

• Tworzenie i wysyłanie requestów HTTP, 
• Tworzenie kolekcji requestów 
• Obsługa parametrów i zmiennych środowiskowych 
• Możliwość tworzenia prostych testów automatyzujących nudne i powtarzalne czynności 

Dzięki tej wtyczce nie musimy się już przełączać pomiędzy aplikacjami jeśli chcemy wysłać request HTTP w celu przetestowania funkcjonalności API nad którym pracujemy. Oczywiście Thunder Client nie jest i nigdy nie będzie zamiennikiem dla Postmana czy Insomni, niemniej do podstawowej pracy z API jest moim zdaniem wystarczający. 

GIT

Kolejnym dodatkiem do VS Code, bez którego nie wyobrażam sobie pracy oprócz samego systemu kontroli wersji GIT, to rozszerzenia dla GIT takie jak GitHistory oraz GitLens. 

GitHistory

Pierwsze pozwala na wygodne przeglądanie historii i loga GIT-a, dzięki przyjemnemu interfejsowi graficznemu. 

GitLens

Drugie to prawdziwy kombajn, który przenosi pracę z GIT-em w Visual Studio Code do wyższego wymiaru. Integrując się z VS Code, dostarcza nam wiele wizualnych narzędzi pozwalających spojrzeć w najgłębsze otchłanie repozytorium, takie jak kto jest autorem danej linii kodu, kiedy ostatni raz była zmodyfikowana i link do commitu, który zawiera ostatnie zmiany powiązane z tą linią kodu oraz wiele wiele innych. 

Database Client

Czym byłoby pisanie aplikacji bez wykorzystywania baz danych? Na rynku dostępnych jest wiele klientów do popularnych silników jak SQL Server Management Studio dla MS SQL Server, pgAdmin dla Postgresa, SQL Developer dla Oracle, czy uniwersalny DBeaver. Z racji tego iż w większości te narzędzia są dedykowane dla konkretnych silników baz danych, to każde z nich oferuje dużo więcej funkcjonalności niż pisanie zapytań i przeglądanie ich zawartości. Standardem w tych narzędziach są profilery, analizatory, narzędzia do diagnostyki i zarządzania całymi stosami baz danych. 

Niemniej jeżeli potrzebujemy podstawowej funkcjonalności takiej jak pisanie zapytań i przeglądanie danych to rozszerzenie Database Client sprawdzi się znakomicie ponieważ podobnie jak w przypadku Thunder Client nie musimy mieć uruchomionej obok Visual Studio Code kolejnej aplikacji i przełączać się między nimi. 

Obecnie Database Client wspiera takie silniki baz danych jak: 

• MySql/MariaDB 
• PostgreSQL 
• SQL Server, 
• SQLite, 
• MongoDB
• Redis 
• Elastic Search 

A także pozwala łączyć się przez SSH do wspomnianych serwerów. 

Terraform

Podejście infrastruktura jako kod (ang. Infrastructure as Code) to już standard we współczesnym IT. Pisałem o tym tutaj Infrastruktura jako kod. Pomimo tego, że każdy dostawca chmurowy oferuje swoje natywne rozwiązanie do IaC takie jak Cloud Formation oraz AWS CDK dla chmury AWS, ARM Templates, Azure CLI czy Bicep dla Microsoftowej chmury Azure, to tam gdzie to możliwe moim zdaniem powinniśmy korzystać z narzędzi które są niezależne od dostawcy. Takim narzędziem niewątpliwie jest Terraform, który dla wielu inżynierów, architektów oraz firm jest już standardem. Wynika to z faktu, że możemy używać jednego narzędzia i jednego języka do pracy z wieloma chmurami.

Terraform to narzędzie konsolowe, co znaczy, że polecenia wydajemy z poziomu terminala oraz język HCL, którego używamy do opisu infrastruktury. Aby usprawnić proces pracy z Terraformem, autorzy narzędzia czyli firma Hashicorp stworzyła rozszerzenie do Visual Studio Code o nazwie Terraform. Dzięki niemu otrzymujemy w edytorze pełne wsparcie dla języka HCL oraz funkcje jak: 

• IntelliSense – automatyczne uzupełnianie nazw dostawców (ang. Providers), zasobów (ang. Resources) oraz ich atrybutów oraz źródeł danych (ang. Data Sources). 
• Sprawdzanie poprawności składni 
• Podświetlanie składni 
• Nawigacja po kodzie 
• Automatyczne formatowanie kodu 
• Snippety, czyli skróty do tworzenia bloków kodu 
• Wyświetlanie wszystkich modułów i dostawców, do których odwołuje się aktualnie otwarty plik 
• Uruchamianie poleceń bezpośrednio z palety poleceń VS Code bez potrzeby ręcznego przełączania się do terminala 

Docker

Konteneryzacja jest niewątpliwie podstawą współczesnych procesów wytwarzania oprogramowania i podstawą rozwoju podejścia cloud-native, a Docker jest wciąż numerem jeden jeśli chodzi o wybór narzędzia do konteneryzacji. Docker jak większość tego typu narzędzi jest narzędziem linii poleceń. Rozszerzenie Docker dla Visual Studio Code dostarcza wygodny UI do pracy poleceniami Docker CLI i pozwala na budowanie, zarządzanie i wdrażanie skonteneryzowanych aplikacji z poziomu Visual Studio Code. Umożliwia również debugowanie aplikacji napisanych w Node.js, Python i .NET wewnątrz działającego kontenera. 

Remote Development 

Jak już jesteśmy przy kontenerach to nie sposób nie wspomnieć o wspaniałym extension packu do Visual Studio Code, czyli VS Code Remote Development – zestawie rozszerzeń w który wchodzą takie wtyczki jak:

• Remote SSH  
• Dev Containers 
• WSL 

Remote SSH

Remote SSH pozwala podłączyć Visual Studio Code do zdalnych folderów znajdujących się na fizycznych serwerach, maszynach wirtualnych czy kontenerach. Wystarczy że zdalna usługa pozwala na dostęp przez SSH. Przykładowo dzięki temu nie musimy pobierać źródeł aplikacji na lokalną stację roboczą, możemy bez problemu uruchomić kod znajdujący się na zdalnym zasobie, korzystając z takich dobrodziejstw VS Code jak: auto-uzupełnianie, nawigacja po kodzie i debugger.

Dev Containers

Dev Containers to prawdziwy game changer w pracy z kontenerami, a zwłaszcza w pracy zespołowej, który zasługuje na osobny obszerny artykuł. Na potrzeby niniejszego artykułu napiszę tylko, że dzięki temu rozszerzeniu możemy wykorzystać Dockera do stworzenia środowiska programistycznego oddzielonego od naszego środowiska lokalnego i współdzielić z innymi osobami pracującymi przy projekcie.

Wyobraźmy sobie że dołączamy do projektu, klonujemy repozytorium i okazuje się że aby zbudować projekt musimy zainstalować wymagane zależności. Dla przykładu niech będzie to .NET Core w wersji 3.1 do backendu, jakaś specyficzna wersja Node.js i menadżer pakietów jak NPM dla aplikacji frontendowej napisanej w Angularze. Do tego dodajmy wymagane rozszerzenia VS Code do Angulara jak Angular Language Service wspierający pisanie kodu w szablonach, określony linter czy prettier do formatowania kodu. Ogólnie konfiguracja środowiska developerskiego nie należy do najciekawszych rzeczy, zwłaszcza gdy pracujemy ze starszym kodem, który wymaga konkretnych wersji środowisk uruchomieniowych i bibliotek. A co gorsza to możemy pracować na kilku projektach wymagających ich różnych wersji, co może prowadzić do konfliktów i problemów z ich kompatybilnością.

Na szczęście dzięki wykorzystaniu rozszerzenia DevContainers deklarujemy wszystkie zależności i konfigurację Visual Studio Code w plikach jak devcontainer.json, Dockerfile czy docker-compose.yml, które commitujemy do repozytorium razem z pozostałymi plikami. Po uruchomieniu tak skonfigurowanego projektu w Visual Studio Code przy użyciu rozszerzenia Dev Containers, będziemy mogli swobodnie programować z poziomu edytora bez konieczności instalacji wspomnianych zależności na lokalnym komputerze. Wszystkie zależności zostaną zainstalowane na odpowiednim kontenerze Docker oraz otrzymamy instancję Visual Studio Code z zainstalowanymi wszystkimi rozszerzeniami wymaganymi do pracy z kodem. Fajnie co?

WSL

WSL to z kolei wybawienie, gdy jestem zmuszony pracować na laptopie z Windowsem, zwykle dostarczanym przez pracodawcę lub klienta który wymaga pracy na swojej stacji roboczej będącej pod kontrolą działu IT. Dzięki WSL na stacji roboczej z systemem Windows mogę zainstalować dystrybucję Linuxa do której mogę się podłączyć z poziomu Visual Studio Code i wygodnie pracować na Linuxie. Podobnie jak w przypadku Dev Containers moja instancja VS Code zainstalowana na którejś z uruchomionych dystrybucji ma swoją specyficzną konfigurację niezależną od konfiguracji VS Code jakiej używam na Windowsie, czy innej dystrybucji, bo WSL pozwala na posiadanie zainstalowanych kilku distro obok siebie. Szczegółowe informacje na temat WSL znajdziemy w oficjalnej dokumentacji pod adresem https://learn.microsoft.com/en-us/windows/wsl/.

Kubernetes

Kubernetes podobnie jak Docker czy Terraform to jedno z najważniejszych narzędzi w podejściu cloud-native. Służy do zarządzania i orkiestracji dziesiątkami a nawet setkami kontenerów i jak większość tego typu rozwiązań jest narzędziem działającym z linii poleceń, dlatego też dla Visual Studio Code stworzono rozszerzenie Kubernetes. Dzięki niemu możemy wykonywać dużą część operacji bezpośrednio z poziomu IDE. Rozszerzenie to pozwala nam zarządzać klastrami Kubernetesa, przeglądać zasoby takie jak Namespaces, Nodes, Network, Storage czy repozytoria Helm.

Ponadto dostajemy wsparcie typu intellisense (podpowiadanie składni) w plikach zasobów Kubernetes oraz Helm chartów, dostęp do logów, snippety oraz scaffolding czyli tworzenie szkieletu plików yaml czy uruchamianie poleceń/tunelu SSH bezpośrednio w/do działających kontenerach/kontenerów.

YAML

Budując rozwiązania natywne dla chmur obliczeniowych (ang. Cloud-Native) nie sposób nie trafić i nie musieć pracować z plikami w formacie .yaml. Nie ma znaczenia czy tworzymy pliki docker-compose, pliki konfiguracyjne dla Kubernetesa czy Helm charty. YAML jest wszędzie. Wyzwaniem w pracy z YAMLem są wcięcia. Tak, YAML jest wrażliwy na wcięcia w tekście. I właśnie dlatego firma RedHat stworzyła rozszerzenie o nazwie YAML, które dostarcza wsparcia w edycji i tworzeniu plików w tym formacie. 

Podsumowanie

Visual Studio Code dzięki swojej koncepcji rozszerzeń oraz otwartości na społeczność open source sprawił, że niemożliwe stało się możliwe. Od teraz dzięki odpowiedniemu dobraniu rozszerzeń do VS Code nawet programiści .NET mogą spróbować przesiąść się z maszyn Windowsowych na Linuxy, co w dobie rozwiązań cloud-native ma jeszcze jedną zaletę – Docker na Linuxie jest natywnie wspierany (nie potrzebujemy dodatkowego hypervisora aby uruchamiać kontenery) co sprawia, że nie potrzebujemy płatnego Docker Desktop aby pracować z kontenerami.

Mam nadzieję, że ta krótka seria programisty .NET na Linuxie była dla Was wartościowa i że udało mi się Was was choć troszkę przekonać do spróbowania swoich programistycznych sił na Linuxie, nawet jeśli pracujecie z technologią od Microsoft jak .NET Core/6+

Wprowadzenie

Cześć, tu Marek z firmy IT w Chmurach. Po dłuższej nieobecności wracamy z nowym wpisem. Dziś chcę pokazać wam w jaki sposób możecie pracować z dotnetem na Linuxie. Mimo upływu lat i zmian jakie przeszedł .NET Framework, wiele osób wciąż myśli że .NET == Windows. Nic bardziej mylnego. Od kilku lat .NET nie dość że jest multi-platformowy, co oznacza, że aplikacje napisane z jego użyciem możemy tworzyć i uruchamiać na takich platformach jak Linux, Mac oraz Windows, to jeszcze jest open source.

Ale, żeby nie było tak kolorowo, to musimy pamiętać, że multi-platformowość dotneta nie dotyczy aplikacji desktopowych. Aplikacje desktopowe napisane w Windows Forms czy WPF (Windows Presentation Foundation) nawet w najnowszej multi-platformowej wersji frameworka czyli .NET 7, w dalszym ciągu będą przywiązane do Windowsa. Wynika to z tego, że cała warstwa graficzna w tym wszystkie biblioteki obsługujące GUI, opierają się o API systemu Windows, które z wiadomych przyczyn nie jest kompatybilne z API interfejsów graficznych Linuxa czy iOSa.

Niemniej dla osób takich jak ja, czyli w większości tworzących przy pomocy .NET aplikacje internetowe oraz usługi, które nie mają swoich interfejsów graficznych, a jeżeli już mają to są one napisane w takich frameworkach jak Angular, React czy Blazor, które działają na wszystkich systemach operacyjnych, desktopowe ograniczenia .NET nie stanowią już problemu. 

Narzędzia

Największym wyzwaniem dla programistów .NET związanym z przesiadką na Linuxa, będzie próba zastąpienia Visual Studio. Niestety mimo wypuszczenia przez Microsoft wersji Visual Studio dla komputerów Mac, wciąż nie ma wersji Visual Studio, która działałaby na Linuxie i nie wiadomo czy w ogóle będzie. To co możemy zrobić w tej sytuacji to: 

• kupić licencję na IDE Rider od JetBrains
• użyć darmowego Visual Studio Code wraz z odpowiednimi wtyczkami, które pozwalają rozszerzyć VS Code o funkcje znane z Visual Studio

Minusem Ridera jest jego cena – 149 Euro za roczną subskrypcję dla osób indywidualnych. Plusem – działa na Linuxie, Windowsie i iOS oraz ma wiele funkcjonalności znanych z Visual Studio, które ułatwiają pracę.

VS Code z kolei jest darmowy, ale ma wiele ograniczeń, które możemy próbować obejść, korzystając z darmowych rozszerzeń i stuningować VS Code tak, aby mieć chociaż część funkcjonalności, jakie oferują wspomniane dwa duże IDE czyli Rider oraz Visual Studio.

Rozszerzenia VS Code dla .NET

C#

Pierwszą rzeczą jaką musimy zrobić po zainstalowaniu runtime i SDK .NET oraz VS Code jest dodanie rozszerzenia C# od Microsoft, które dostarcza narzędzia integrujące Visual Studio Code z kompilatorem oraz narzędzia do uruchamiania oraz debugowania kodu C#. Dzięki temu możemy uruchamiać aplikacje dotnetowe za pomocą klawisza F5, otrzymujemy debugger, oraz obsługę skrótów takich jak idź do implementacji czy idź do definicji. 

Mając zainstalowane rozszerzenie C#, utwórzmy przykładowy projekt ASP.NET Core i spróbujmy go uruchomić z poziomu VS Code. W tym celu przechodzimy do folderu w którym znajdzie się nasz projekt, z poziomu terminala wydajemy polecenie:

dotnet new webapp

Po utworzeniu projektu otwieramy go w Visual Studio Code za pomocą komendy:

code .

Wciskamy klawisz F5 i czekamy aż aplikacja się zbuduje i uruchomi. W przeglądarce powinna otworzyć się strona startowa aplikacji więc pierwszy krok za nami. 

Roslynator

Roslynator to jak nazwa wskazuje rozszerzenie wykorzystujące możliwości kompilatora Roslyn. Roslyn to kompilator open-source oferujący API dla języków C# i Visual Basic (VB.NET) dostarczający takich funkcji jak IntelliSense, nawigacja po kodzie, kolorowanie składni, analiza kodu i refaktoryzacja. Dzięki temu programiści mogą tworzyć swoje narzędzia do analizy kodu i refaktoryzacji. Przykładem takiego narzędzia jest właśnie Roslynator.

Spójrzmy na działanie Roslyn w praktyce. W poniższym kawałku kodu zagnieździliśmy dyrektywę using wewnętrz innej dyrektywy using. Jak widzimy przy wewnętrznym usingu pojawiło się podkreślenie sugerujące że coś możemy poprawić. Po najechaniu kursorem myszki pojawia się komunikat z kompilatora, że to wyrażenie może zostać uproszczone. 

Po zastosowaniu sugerowanych zmian otrzymamy następujący kod: 

Identyczne działanie zobaczymy w przypadku zagnieżdżonych instrukcji warunkowych, automatycznego uzupełniania wyrażeń switch-case, refaktoringu i wielu innych rzeczy. 

VS Code Solution Explorer

Kolejnym krokiem będzie zainstalowanie rozszerzenia o nazwie vscode-solution-explorer. Dzięki niemu otrzymujemy w Visual Studio Code panel widoku solucji znany z Visual Studio:

Dzięki temu rozszerzeniu możemy w łatwy sposób: 

• Tworzyć solucje
• Dodawać nowe projekty do solucji oraz je usuwać
• Dodawać pliki klas, interfejsów, enumów oraz kontrolery na podstawie szablonów z możliwością tworzenia swoich własnych
• Dodawać, usuwać referencje w projektach 
• Zarządzać paczkami z repozytorium NuGet 
• Budować, publikować, uruchamiać testy i wiele więcej

Oczywiście wszystkie te operacje możemy również wykonać z poziomu linii poleceń, ponieważ to rozszerzenie jest niczym innym jak nakładką graficzną i pod spodem wywoływane są normalne komendy dotnet CLI, co możemy zobaczyć w trakcie dodawania z poziomu vscode explorera do solucji projektu z testami xUnit, przełączając się na widok terminala:

.NET Core Test Explorer 

Pisanie testów czy to jednostkowych, integracyjnych, wydajnościowych czy jeszcze innych jest dobrą praktyką. Nie ma co tu nawet dyskutować. Aby w VS Code uruchamiać testy napisane w MSUnit, xUnit czy NUnit będziemy potrzebować dedykowanego rozszerzenia. Ja korzystam z .NET Core Test Explorer. Po zainstalowaniu rozszerzenia w pasku bocznym pojawi się ikona kolby Erlenmayera (stożkowe szkło laboratoryjne). Po przełączeniu się na widok eksploratora testów, zostaną wykryte wszystkie testy w solucji. Testy możemy uruchamiać klikając myszką na przycisk „play” w eksploratorze albo za pomocą skrótów klawiszowych (domyślnie Alt+R Alt+A).

Jak widzimy powyższy test zakończył się błędem mówiącym, że wskazany endpoint naszego API który chcieliśmy przetestować integracyjnie nie istnieje. Informacja o wyniku testu jest prezentowana w formie dużej ikonki X tuż nad sygnaturą metody testującej.

Podsumowanie

Powyższe rozszerzenia to absolutne minimum do tego, aby rozpocząć przygodę z programowaniem w dotnecie na Linuxie. Jeżeli znacie inne warte uwagi, koniecznie wspomnijcie o nich w komentarzu, a w kolejnym poście pokażę kilka dodatkowych rozszerzeń do VS Code, które nie są związane wyłącznie z programowaniem w .NET, ale usprawniają moją codzienną pracę.

Bonus – Material Icon Theme 

Dla osób, które tak jak ja przywiązują dużą wagę do wyglądu swojego IDE polecam rozszerzenie Material Icon Theme, które pozwoli zamienić standardowe ikony VS Code w te znane z Material Design.