Instalacja .NET SDK i pierwszy program, krok po kroku

Na końcu mają działać dwa polecenia. dotnet --info odpowiada numerem wersji, a dotnet run uruchamia program, który wypisuje tekst w konsoli. Instalacja .NET SDK sprowadza się do pobrania jednego pliku i uruchomienia go. Kłopoty zaczynają się krok później.

Krok 0: sprawdź, czy nie masz już SDK

Zanim cokolwiek pobierzesz, otwórz PowerShell i wpisz:

dotnet --list-sdks

Jeśli zobaczysz linię z numerem i ścieżką, SDK jest już zainstalowane:

10.0.400 [C:\Program Files\dotnet\sdk]

Wtedy instalator jest zbędny. Visual Studio, Rider i część narzędzi instalują SDK przy okazji, więc ta linia pojawia się częściej, niż wynikałoby z pamięci o tym, co się instalowało na tej maszynie przez ostatni rok. Puste wyjście albo komunikat o nieznanym poleceniu znaczy, że idziesz dalej.

Warto zrobić ten jeden krok, bo druga instalacja obok istniejącej nie kończy się błędem. Kończy się dwiema wersjami, z których jedna jest pierwsza w PATH, i tygodniem zastanawiania się, dlaczego edytor widzi coś innego niż terminal.

Instalator i weryfikacja

Instalator dla Windows x64 pobierzesz ze strony .NET. Plik ma około 200 MB i po uruchomieniu nie zadaje żadnych pytań poza zgodą na instalację. Nie ma tu nic do wybrania, żadnych komponentów opcjonalnych ani katalogu docelowego. DevJourney wymaga wersji 10, tej samej, którą pobiera domyślny przycisk na tej stronie.

Po instalacji zamknij terminal i otwórz nowy. Potem:

dotnet --info

Odpowiedź jest długa i to jest jej zaleta. Zawiera wszystko, o co trzeba by pytać osobno, a przy zgłaszaniu problemu na forum jest pierwszą rzeczą, o którą poprosi każdy, kto zamierza pomóc.

Trzy różne numery w jednej odpowiedzi

Ta sama odpowiedź podaje kilka wersji i one nie są tym samym numerem zapisanym w kilku miejscach:

.NET SDK:
 Version:           10.0.400
 Commit:            14fbf8d527
 MSBuild version:   18.9.6+14fbf8d52

Runtime Environment:
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\10.0.400\

Host:
  Version:      10.0.11
  Architecture: x64

Numery przy SDK i przy Host różnią się i tak ma być. Pierwszy opisuje narzędzia, którymi kompilujesz, drugi środowisko uruchomieniowe, które wykonuje gotowy program. SDK aktualizuje się częściej, bo zmiany w kompilatorze i w szablonach nie wymagają ruszania tego, co uruchamia skompilowany kod.

Osobne polecenie pokazuje, ile środowisk stoi obok siebie:

dotnet --list-runtimes

Na tej maszynie wypisuje między innymi to:

Microsoft.NETCore.App 9.0.19 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Dwie linie tej samej rodziny, jedna z dziewiątki i jedna z dziesiątki. Starsza została po poprzednim SDK i jest potrzebna, bo program zbudowany na dziewiątkę nadal jej szuka przy uruchomieniu. Do tej listy wracasz wtedy, gdy program uruchamia się u Ciebie, a u kogoś innego nie. Usuwanie starych środowisk niczego nie przyspiesza. Zajmują miejsce na dysku i tyle.

Niżej dotnet --info potrafi wypisać jeszcze coś takiego:

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]

To druga, osobna instalacja, w innej architekturze, zwykle zostawiona przez jakiś instalator. Nie przeszkadza, dopóki where dotnet wskazuje katalog bez (x86) w nazwie. Jeśli wskazuje ten z (x86), kolejność wpisów w PATH jest odwrotna, niż powinna być, i to jest moment na jej poprawienie.

Pierwszy program w dwóch poleceniach

Szablon konsolowy tworzy się jednym poleceniem:

dotnet new console -o witaj
cd witaj
dotnet run

Pierwsze z nich wypisuje po polsku, jeśli język interfejsu systemu jest polski:

Pomyślnie utworzono szablon "Aplikacja konsoli".

Trwa przetwarzanie akcji po utworzeniu...
Przywracanie pakietu C:\...\witaj\witaj.csproj:
  Trwa określanie projektów do przywrócenia...
  Przywrócono element C:\...\witaj\witaj.csproj (w 92 ms).
Przywracanie powiodło się.

Ostatnie dwie linie tego wyjścia znaczą, że przywracanie pakietów już się odbyło. Osobne dotnet restore jest więc niepotrzebne, choć połowa poradników każe je uruchomić zaraz po utworzeniu projektu.

Powstają dwa pliki. witaj.csproj opisuje projekt, a Program.cs zawiera kod, i na starcie jest to jedna linia:

Console.WriteLine("Hello, World!");

Nie ma tu klasy, metody Main ani żadnej deklaracji wokół. Kompilator dopisuje je sam przy budowaniu, a plik zostaje przy jednej instrukcji. Starsze kursy pokazują w tym miejscu kilkanaście linii i to nie jest błąd w nich, tylko poprzednia konwencja szablonu.

Katalog obj, który pojawia się obok, jest wynikiem przywracania pakietów i nie jest częścią Twojego kodu. W witaj.csproj liczy się jeden wiersz:

<TargetFramework>net10.0</TargetFramework>

To on decyduje, na której wersji platformy program zostanie zbudowany, i to jego zmienia się przy przenoszeniu projektu na inną wersję. Numer w tym wierszu nie musi być zgodny z numerem SDK. Zgodny musi być z którymś ze środowisk z listy dotnet --list-runtimes.

Pierwsze dotnet run na czystej maszynie zajęło 6,5 sekundy. Drugie, bez zmian w kodzie, 2,5 sekundy. Różnica to kompilacja, która przy pierwszym uruchomieniu wykonuje się w całości, a potem odpada aż do następnej zmiany w pliku. Jeśli więc pierwsze uruchomienie wygląda na zawieszone, jeszcze nie jest.

Przy zupełnie pierwszym poleceniu dotnet na nowym systemie dochodzi jeszcze jedno. Wypisuje się powitanie z numerem wersji, informacja o zbieranej telemetrii i linia o certyfikacie:

Installed an ASP.NET Core HTTPS development certificate.
To trust the certificate, run 'dotnet dev-certs https --trust'

Certyfikat przyda się dopiero przy aplikacjach webowych, przy pierwszym adresie otwieranym po https. Zobaczysz to raz.

Kiedy „dotnet” nie jest rozpoznawane

Najczęstszy problem po poprawnej instalacji wygląda tak:

'dotnet' is not recognized as an internal or external command,
operable program or batch file.

W PowerShellu ten sam brak brzmi inaczej:

The term 'dotnet' is not recognized as the name of a cmdlet, function, script
file, or operable program.

Komunikat pochodzi z powłoki, nie z .NET, więc pojawia się w języku interfejsu systemu. Na polskim Windowsie zaczyna się od słów o nierozpoznanym poleceniu wewnętrznym lub zewnętrznym. Treść jest ta sama.

Przyczyna prawie zawsze jest jedna. Instalator dopisał C:\Program Files\dotnet\ do zmiennej PATH, ale terminal otwarty wcześniej wczytał starą zawartość tej zmiennej w chwili startu i nic go nie zmusi do ponownego odczytu. Zamknij okno i otwórz nowe. Sprawdzisz to poleceniem:

where dotnet

Poprawna odpowiedź to C:\Program Files\dotnet\dotnet.exe. Brak odpowiedzi po restarcie terminala znaczy, że instalator nie dokończył pracy i warto uruchomić go ponownie. Restart całego systemu bywa zalecany w odpowiedziach na forach i prawie nigdy nie jest potrzebny.

Projekt żąda wersji, której nie masz

Drugi błąd jest ciekawszy, bo pojawia się dopiero w konkretnym katalogu. To samo polecenie działa piętro wyżej i przestaje działać po wejściu do projektu:

  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 9.0.100
global.json file: C:\...\global.json

Installed SDKs:
10.0.400 [C:\Program Files\dotnet\sdk]

Install the [9.0.100] .NET SDK or update global.json to match an installed SDK.

Winny jest plik global.json, który przypina projekt do wskazanej wersji SDK. Repozytoria z kursów i firmowe szablony noszą go często, a że leży w katalogu głównym projektu i ma kilka linii, łatwo go przeoczyć przy pobieraniu cudzego kodu. Masz dwa wyjścia: doinstalować żądaną wersję albo podnieść numer w pliku do tego, co pokazuje dotnet --list-sdks. Wiele wersji SDK stoi obok siebie bez konfliktu, więc pierwsze wyjście nie psuje niczego, co już działa.

Ten komunikat wypisuje host, a nie interfejs wiersza poleceń, więc zostaje angielski nawet przy polskim systemie. Zmienna DOTNET_CLI_UI_LANGUAGE na niego nie działa i szukanie polskiej wersji tego tekstu nie ma sensu.

Instalacja .NET SDK kończy się w chwili, w której dotnet --info i dotnet run odpowiadają tym, czego się spodziewasz. Następny komunikat będzie już od kompilatora, a najczęstszy z nich to CS0029 przy przypisaniu typów.

DevJourney uruchamia te same polecenia wewnątrz aplikacji, na prawdziwym dotnet, bez konfigurowania czegokolwiek osobno.