5 Kluczowych Komend CLI .NET, Które Każdy Deweloper Powinien Znać

Sprawdzanie swojego środowiska za pomocą dotnet --info

[0:31 - 1:25] Zanim uruchomimy jakiekolwiek komendy projektowe, Tim zaczyna od sprawdzenia środowiska deweloperskiego. Polecenie dotnet samo w sobie potwierdza, że CLI jest zainstalowane i dostępne w twojej ścieżce, ale dotnet --info idzie dalej:

dotnet --info

dotnet --info

To wypisuje każdy zainstalowany SDK i wersję runtime na Twojej maszynie, wraz z szczegółami systemu operacyjnego i aktywną architekturą. Tim demonstruje to na .NET 10, ale komenda działa identycznie na każdej wersji. Wiedza o tym, co masz zainstalowane, jest szczególnie pomocna przy debugowaniu niezgodności wersji lub weryfikacji, że serwer CI odzwierciedla Twoją lokalną konfigurację.

Komenda 1: dotnet build

[2:16 - 3:44] Pierwsza komenda kompiluje Twój projekt bez jego uruchamiania:

dotnet build

dotnet build

Uruchomienie tego z katalogu projektu odczytuje plik .csproj, rozwiązuje zależności i produkuje skompilowany wynik w folderze bin. Tim podkreśla, że kompilacja to oddzielny krok, różniący się od wykonania. To oddzielenie ma znaczenie, gdy chcesz zweryfikować, czy Twój kod kompiluje się poprawnie, zanim wypchniesz go do repozytorium lub przekażesz do serwera build.

.NET SDK zajmuje się rozwiązywaniem zależności podczas procesu kompilacji, pobierając wszelkie brakujące pakiety NuGet i zapewniając, że wszystkie referencyjne asemblice są obecne. Jeśli coś na tym etapie zawiedzie, wiadomości o błędach wskazują na problem bezpośrednio, niezależnie od tego, czy jest to brakująca referencja, błąd składni, czy niezgodność docelowej platformy. Wychwytywanie tych problemów przed uruchomieniem aplikacji oszczędza czas w całym cyklu rozwojowym.

Komenda 2: dotnet run

[3:44 - 5:42] Gdzie build zatrzymuje się na kompilacji, run wykonuje kolejny krok i uruchamia aplikację:

dotnet run

dotnet run

Kompiluje projekt (jeśli to potrzebne) i następnie wykonuje wynikowy kod. Dla aplikacji konsolowej oznacza to jej uruchomienie w terminalu. Dla projektu webowego, wbudowany serwer Kestrel uruchamia się i aplikacja staje się dostępna pod lokalnym URL.

Tim pokazuje to na aplikacji webowej, nawigując do uruchomionej strony w przeglądarce, aby potwierdzić, że wszystko ładuje się poprawnie. Kluczowa różnica między build a run polega na tym, że run daje rezultat na żywo i interaktywny. Podczas aktywnego rozwoju, to jest komenda, której używasz najczęściej, aby testować zmiany i zobaczyć ich efekt.

Komenda 3: dotnet watch

[5:42 - 7:06] Zatrzymanie aplikacji, wprowadzenie zmiany i jej ponowne uruchomienie szybko staje się uciążliwe. Polecenie watch eliminuje ten cykl:

dotnet watch

dotnet watch

To opakowuje proces uruchamiania w obserwator plików. Kiedy zapiszesz zmianę w dowolnym pliku źródłowym, CLI wykrywa modyfikację i automatycznie kompiluje oraz odświeża aplikację. Dla aplikacji webowych zbudowanych przy użyciu ASP.NET Core, zmiany w plikach Razor, CSS i kodzie C# pojawiają się w przeglądarce bez potrzeby ręcznego restartu.

Tim pokazuje działanie hot reload: edytowanie strony, zapisywanie i natychmiastowe odzwierciedlenie aktualizacji. Ten szybki pętla zwrotna jest cenna podczas pracy nad interfejsem użytkownika, gdzie drobne korekty są dokonywane stale. Zamiast cyklu zatrzymanie-edycja-przebudowa-uruchomienie, skupiasz się na kodzie, a narzędzia zajmują się resztą.

Komenda 4: dotnet clean

[7:06 - 7:56] Artefakty kompilacji gromadzą się w katalogach bin i obj z czasem. Czasami przestarzałe skompilowane pliki powodują mylące zachowanie, gdzie najnowsze zmiany kodu wydają się nie wchodzić w życie, lub gdy kompilacja się udaje lokalnie, ale nie na nowej maszynie. Polecenie clean rozwiązuje ten problem:

dotnet clean

dotnet clean

Uruchomienie jej usuwa zawartość katalogów wyjściowych, dzięki czemu kolejna budowa zaczyna się od zera. Tim przedstawia to jako narzędzie do rozwiązywania problemów, a nie coś, co uruchamiasz po każdej zmianie. Kiedy twój projekt zachowuje się nieoczekiwanie i podejrzewasz, że winny jest zbuforowany wynik, clean, a następnie build zapewniają, że pracujesz z naprawdę świeżą kompilacją.

Ten nawyk jest szczególnie przydatny podczas zmiany gałęzi w kontroli wersji, aktualizacji zależności do nowej głównej wersji lub rozwiązywania sporadycznych ostrzeżeń kompilacji, które pojawiają się i znikają bez wyraźnej przyczyny.

Komenda 5: dotnet publish

[7:56 - 9:01] Ostateczna komenda pomostuje lukę między rozwojem a wdrożeniem:

dotnet publish

dotnet publish

Podczas gdy build produkuje wynik odpowiedni do lokalnego debugowania, publish tworzy paczkę gotową do wdrożenia. Skompilowane zestawy, pliki konfiguracyjne, zasoby statyczne oraz wszelkie wymagane komponenty wykonawcze trafiają do folderu publish, który można bezpośrednio skopiować na serwer.

Różnica między build a publish zaskakuje niektórych programistów. Wynik build zawiera symbole debugowania i odwołania, które są przydatne podczas rozwoju, ale niepotrzebne (a czasami niepożądane) w środowisku produkcyjnym. Publikacja usuwa te dodatki i organizuje dane wyjściowe dla docelowego środowiska. Podczas wdrażania do Docker lub przesyłania do hostingu w chmurze, publikowane dane wyjściowe to te, które należy znaleźć w twoim końcowym obrazie lub pakietie wydaniowym.

Podsumowanie: Pięć Komend, Jeden Workflow

[9:01 - 9:15] Tim kończy, wymieniając wszystkie pięć razem: dotnet build, dotnet run, dotnet watch, dotnet clean, oraz dotnet publish. Ujęte jako zestaw, obejmują główną pętlę deweloperską od kompilacji po wdrożenie. Każda służy określonemu celowi, a znajomość, kiedy sięgnąć po każdą, daje poziom kontroli, którego samo klikanie przycisków IDE nie zapewnia.

Wnioski

[9:15 - 9:30] Te pięć komend CLI obsługuje zadania, które najczęściej wykonujesz podczas rozwoju: kompilację, uruchamianie, żywe przeładowanie, czyszczenie przestarzałych danych wyjściowych i pakowanie na wydanie. Działają one we wszystkich typach projektów .NET i na każdym systemie operacyjnym obsługiwanym przez SDK.

Następnym razem, gdy otworzysz terminal, niezależnie czy na lokalnej maszynie, wewnątrz kontenera, czy na zdalnym serwerze, już masz wystarczającą wiedzę, aby przejść przez cały cykl deweloperski bez interfejsu graficznego.

Przykładowa wskazówka: Możesz połączyć clean oraz build w jednej linii z dotnet clean && dotnet build. To gwarantuje kompilację "od zera" w jednym kroku, co jest szczególnie przydatne podczas rozwiązywania problemów, które utrzymują się pomimo stopniowych kompilacji.

Obejrzyj pełny film na jego Kanale YouTube i zyskaj więcej wglądu w kluczowe elementy .NET CLI.