Niedziałające dotnet run wskazuje na błąd kompilacji projektu lub brak wygenerowanych plików pośrednich w katalogu obj/bin.
Co oznacza problem z poleceniem dotnet run
Polecenie dotnet run służy do uruchomienia projektu .NET z poziomu wiersza poleceń. W typowym przypadku jest wykonywane w katalogu zawierającym plik projektu, na przykład .csproj. Przed uruchomieniem aplikacji narzędzie .NET ustala projekt, przywraca zależności NuGet, buduje kod i dopiero potem uruchamia wygenerowany program. Dlatego komunikat, że dotnet run nie działa, nie oznacza jednej konkretnej usterki. Przyczyną może być brak zestawu .NET SDK, błędy w kodzie C#, nieprawidłowa konfiguracja projektu, brak pakietu NuGet albo uruchomienie komendy w niewłaściwym katalogu.
Istotne jest rozróżnienie między .NET SDK a samym środowiskiem uruchomieniowym .NET Runtime. Runtime pozwala uruchamiać gotowe aplikacje, natomiast dotnet run wymaga SDK, ponieważ wykonuje również kompilację projektu. Obecność pliku wykonywalnego dotnet.exe w systemie nie gwarantuje więc, że zainstalowano właściwe komponenty deweloperskie. Podstawową kontrolę można rozpocząć od komend dotnet --info oraz dotnet --list-sdks. Pierwsza pokazuje informacje o środowisku, a druga listę dostępnych wersji SDK.
Rozpoznanie projektu i wybór zestawu SDK
Jeżeli polecenie jest wykonywane poza katalogiem projektu, narzędzie może zgłosić brak projektu do uruchomienia. W takiej sytuacji należy sprawdzić bieżącą ścieżkę i zawartość katalogu, a następnie przejść do miejsca, w którym znajduje się właściwy plik .csproj. Gdy projekt znajduje się w innym miejscu lub rozwiązanie zawiera kilka projektów, można wskazać plik jawnie, na przykład dotnet run --project .\src\Aplikacja\Aplikacja.csproj. Rozszerzenie .sln opisuje rozwiązanie, ale samo uruchomienie zwykle dotyczy konkretnego projektu wykonywalnego.
Na wybór używanej wersji SDK może wpływać plik global.json. Jeżeli wymaga on wersji, której nie ma w systemie, polecenie może zakończyć się komunikatem o braku zgodnego zestawu SDK. Należy wtedy porównać wartość wskazaną w global.json z wynikiem dotnet --list-sdks. Osobną kwestią jest framework docelowy określony w pliku projektu przez element TargetFramework lub TargetFrameworks. SDK może być zainstalowane, ale brak odpowiedniego runtime’u dla wskazanego frameworka może uniemożliwić start aplikacji po udanej kompilacji.
W systemie Windows warto również sprawdzić, czy komenda dotnet jest dostępna w zmiennej środowiskowej PATH. Błąd typu „dotnet nie jest rozpoznawany jako polecenie” wskazuje na problem z instalacją albo konfiguracją ścieżki, a nie na błąd samego projektu. W środowisku z kilkoma instalacjami .NET pomocne jest porównanie lokalizacji zwracanej przez where dotnet z oczekiwaną instalacją SDK.
Błędy przy przywracaniu zależności i kompilacji
dotnet run może nie dojść do etapu uruchamiania, ponieważ najpierw wykonuje operacje potrzebne do zbudowania projektu. Błąd przywracania pakietów NuGet może wynikać z braku dostępu do źródła pakietów, niezgodnej wersji zależności, uszkodzonego pliku projektu albo problemu z plikiem NuGet.Config. Komenda dotnet restore pozwala wyodrębnić etap pobierania i rozwiązywania zależności od późniejszej kompilacji. Jeżeli przywracanie kończy się błędem, ponowne uruchamianie dotnet run bez usunięcia przyczyny nie rozwiąże problemu.
Błędy kompilatora C# są zwykle podawane z kodem, nazwą pliku i numerem wiersza. Należy analizować pierwszy istotny komunikat, ponieważ kolejne błędy mogą być tylko skutkiem tej samej niezgodności. Typowe przykłady to brak typu lub przestrzeni nazw, niezgodność typów, błędna składnia, brak implementacji wymaganej metody albo odwołanie do symbolu dostępnego w innej wersji pakietu. Polecenie dotnet build jest przydatne do sprawdzenia samej kompilacji bez uruchamiania aplikacji. Dopóki budowanie kończy się niepowodzeniem, dotnet run nie ma poprawnego programu wynikowego do wystartowania.
Katalogi obj i bin zawierają pliki pośrednie oraz wyniki budowania. Ich brak może być normalny przed pierwszą kompilacją, ale nieprawidłowe lub niepełne pliki w tych katalogach mogą powodować wtórne komunikaty o braku danych wejściowych albo wyników. Bezpiecznym testem jest użycie dotnet clean, a następnie dotnet restore i dotnet build. Ręczne usuwanie katalogów obj i bin bywa stosowane przy uszkodzonym stanie pośrednim, lecz powinno obejmować wyłącznie katalogi należące do danego projektu. Nie zastępuje to analizy właściwego błędu kompilacji, konfiguracji ani zależności.
Uruchomienie programu po usunięciu przyczyny
Po pomyślnym przywróceniu pakietów i zbudowaniu projektu należy sprawdzić, czy uruchamiany jest właściwy typ aplikacji. Projekt biblioteki klas nie jest samodzielnym programem i nie powinien być traktowany jak aplikacja wykonywalna. W przypadku projektu konsolowego dotnet run uruchamia wygenerowany program, natomiast aplikacje webowe mogą dodatkowo korzystać z ustawień profilu startowego, zmiennych środowiskowych oraz konfiguracji zawartej w Properties\launchSettings.json. Brak tego pliku nie zawsze jest błędem, ale może zmienić adres nasłuchiwania lub sposób przekazywania argumentów.
Jeżeli kompilacja przechodzi, lecz aplikacja kończy się natychmiast po starcie, trzeba odróżnić błąd uruchomieniowy od błędu polecenia. Przydatne jest przekazanie argumentów po separatorze --, na przykład dotnet run -- --help, ponieważ wszystko po separatorze trafia do uruchamianej aplikacji. Należy także sprawdzić wyjątek wyświetlony w konsoli, wymagane zmienne środowiskowe, dostęp do plików konfiguracyjnych oraz port używany przez aplikację. W przypadku komunikatu o zajętym porcie problem dotyczy procesu już korzystającego z danego portu, a nie katalogów obj lub bin.
Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC oraz ich podzespołów, w tym diagnostyką problemów z uruchamianiem popularnego oprogramowania i środowiska pracy. W praktyce analiza niedziałającego dotnet run powinna obejmować kolejno instalację SDK, wybór wersji przez global.json, lokalizację projektu, przywracanie pakietów, wynik kompilacji oraz właściwy komunikat pojawiający się podczas startu programu.
