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

Sprawdzanie swojego środowiska za pomocą .NET --info

[0:31 - 1:25] Zanim uruchomimy jakiekolwiek komendy projektowe, Tim zaczyna od sprawdzenia środowiska deweloperskiego. Komenda dotnet sama potwierdza, że CLI jest zainstalowane i dostępne w ś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ę.

Polecenie 1: .NET build

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

dotnet build

dotnet build

Uruchomienie tego z katalogu projektu wczytuje plik .csproj, rozwiązuje zależności i generuje 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.

Polecenie 2: .NET run

[3:44 - 5:42] Gdzie build kończy się na kompilacji, run podejmuje 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 żywy, interaktywny wynik. Podczas aktywnego rozwoju, to jest komenda, której używasz najczęściej, aby testować zmiany i zobaczyć ich efekt.

Polecenie 3: .NET watch

[5:42 - 7:06] Zatrzymanie aplikacji, wprowadzenie zmiany i jej ponowne uruchomienie szybko staje się uciążliwe. Komenda 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ą.

Polecenie 4: .NET clean

[7:06 - 7:56] Artefakty budowy gromadzą się w katalogach bin i obj z czasem. Czasami przestarzałe skompilowane pliki powodują mylące zachowanie, gdy najnowsze zmiany kodu wydają się nie mieć efektu, lub gdy budowa udaje się lokalnie, ale nie udaje się na nowej maszynie. Komenda clean radzi sobie z tym:

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. Gdy twój projekt zachowuje się nieoczekiwanie i podejrzewasz, że przyczyną są dane w cache'u, 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.

Polecenie 5: .NET publish

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

dotnet publish

dotnet publish

Podczas gdy build generuje dane wyjściowe odpowiednie do lokalnego debugowania, publish tworzy pakiet gotowy do wdrożenia. Skompilowane asemblery, pliki konfiguracyjne, zasoby statyczne oraz wszelkie wymagane komponenty wykonawcze trafiają do folderu publish, który można bezpośrednio skopiować na serwer.

Rozróżnienie między build a publish zaskakuje niektórych deweloperów. Wynik build zawiera symbole debugowania i odwołania, które są przydatne podczas rozwoju, ale niekonieczne (a czasami niepożądane) w produkcji. 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] Na zakończenie Tim wymienia wszystkie pięć razem: dotnet build, dotnet run, dotnet watch, dotnet clean i 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 i build w jedną linię za pomocą 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.