.NET SDK nie wykrywa projektów

Gdy .NET SDK nie wykrywa projektów, przyczyną bywa niezgodność wersji w pliku global.json z zainstalowanymi SDK lub uszkodzona struktura katalogu projektu — sprawdzenie "dotnet --list-sdks" pokazuje dostępne wersje.

Czym oznacza problem „.NET SDK nie wykrywa projektów”

Komunikat lub zachowanie polegające na tym, że .NET SDK nie znajduje projektów, oznacza, że narzędzia uruchamiane z wiersza poleceń nie potrafią poprawnie rozpoznać pliku projektu, rozwiązania albo właściwego środowiska kompilacji. W praktyce może pojawić się sytuacja, w której polecenie dotnet build, dotnet restore albo dotnet run zostaje wykonane w niewłaściwym katalogu, nie odnajduje pliku .csproj lub .sln, bądź korzysta z innej wersji zestawu SDK niż ta przewidziana dla danego kodu.

Samo zainstalowanie platformy .NET nie gwarantuje jeszcze prawidłowego wykrywania projektów. Wymagane jest zachowanie zgodności pomiędzy lokalizacją plików, strukturą katalogów, ustawieniami rozwiązania oraz wersją narzędzi używaną podczas pracy. Znaczenie może mieć także plik global.json, który wskazuje oczekiwaną wersję SDK dla danego drzewa katalogów. Jeżeli wskazanie nie odpowiada wersjom obecnym w systemie albo ustawiono tryb wymagający dokładnego dopasowania, polecenia mogą kończyć się błędem mimo obecności plików projektu.

Problem może dotyczyć zarówno nowo utworzonego projektu, jak i wcześniej działającego rozwiązania przeniesionego na inny komputer, odtworzonego z kopii lub pobranego z repozytorium. Dlatego istotne jest ustalenie, czy nie wykrywa się jednego projektu, całego rozwiązania, czy wszystkich projektów uruchamianych w danym środowisku.

Kontekst techniczny i sposób rozpoznawania projektu

.NET SDK wyszukuje projekty na podstawie bieżącej ścieżki oraz parametrów przekazanych do polecenia. Przy pracy z pojedynczym projektem punktem odniesienia jest plik .csproj, natomiast przy pracy z rozwiązaniem może nim być plik .sln lub nowszy format rozwiązania. Jeżeli konsola została otwarta poziom wyżej, poziom niżej albo w katalogu zawierającym kilka niezależnych części aplikacji, automatyczne wyszukiwanie może nie wskazać właściwego celu.

W pierwszej kolejności warto sprawdzić bieżący katalog oraz wyświetlić jego zawartość. W systemie Windows pomocne może być polecenie dir, a w środowiskach uniksowych ls. Następnie należy ustalić, czy w odpowiednim miejscu rzeczywiście znajduje się plik projektu. Można też wskazać go bezpośrednio, na przykład przez użycie ścieżki do pliku przy poleceniu dotnet build. Takie wywołanie pozwala rozdzielić problem z odnajdywaniem projektu od problemu z samą kompilacją.

Drugim obszarem jest wybór SDK. Polecenie dotnet --list-sdks pokazuje zestawy dostępne lokalnie, a dotnet --version informuje, który z nich jest używany w bieżącym miejscu. Należy porównać te informacje z treścią pliku global.json, zwracając uwagę na numer wersji oraz sposób obsługi braku idealnego dopasowania. Jeżeli plik został odziedziczony z innego środowiska, może wymagać aktualizacji, usunięcia albo dostosowania do rzeczywiście zainstalowanego SDK.

Nie należy utożsamiać wszystkich komunikatów z jedną przyczyną. Błąd dotyczący braku SDK, błąd odnalezienia projektu, nieudane przywracanie zależności i błąd kompilacji powstają na różnych etapach. Rozdzielenie tych etapów ułatwia diagnostykę i ogranicza przypadkowe zmiany w konfiguracji.

Typowe problemy i błędy prowadzące do niewykrywania projektów

Częstym źródłem trudności jest uruchomienie polecenia w katalogu, w którym nie ma pliku projektu ani rozwiązania. Zdarza się to po otwarciu nowego terminala, zmianie nazwy folderu, rozpakowaniu archiwum do dodatkowego podkatalogu albo przejściu do katalogu zawierającego jedynie dokumentację i pliki konfiguracyjne. Pomocne jest odszukanie plików .csproj oraz .sln w całym obszarze roboczym i zapisanie właściwej ścieżki.

Inny przypadek występuje wtedy, gdy rozwiązanie zawiera odwołanie do projektu, który został przeniesiony, przemianowany lub pominięty podczas kopiowania. Wtedy plik rozwiązania może się otwierać, lecz część elementów pozostaje niedostępna. Należy sprawdzić ścieżki zapisane w rozwiązaniu, wpisy dotyczące projektów oraz ewentualne komunikaty o brakujących plikach. Przy pracy w edytorze kodu warto również upewnić się, czy otwarto właściwy folder główny, a nie pojedynczy podfolder.

Problemy mogą wynikać także z pliku global.json umieszczonego w bieżącym katalogu lub w jednym z katalogów nadrzędnych. Jego działanie obejmuje określone drzewo folderów, dlatego nie zawsze jest widoczne na pierwszy rzut oka. Nieprawidłowa wersja SDK, ograniczenie do dokładnie wskazanego zestawu albo brak wymaganych komponentów może zablokować dalszą pracę. Dodatkowych wskazówek dostarczają polecenia dotnet --info i dotnet --list-sdks.

Warto zwrócić uwagę na sytuacje, w których projekt jest wykrywany, ale nie przechodzi przywracania zależności. W takim przypadku problem może dotyczyć źródeł pakietów, plików blokady, uprawnień do katalogu lub ustawień sieciowych, a nie samego wyszukiwania projektu. Podobnie uszkodzone pliki tymczasowe, niepełne rozpakowanie katalogu i konflikty między instalacjami narzędzi mogą powodować mylące objawy. Bezpieczna diagnostyka powinna polegać na odczytaniu pełnego komunikatu, sprawdzeniu ścieżki i wersji SDK oraz wykonaniu testu na jednoznacznie wskazanym pliku.

W jakich sytuacjach warto zgłosić sprzęt do serwisu - .NET SDK nie wykrywa projektów

Zgłoszenie do serwisu jest uzasadnione, gdy problem powtarza się mimo wejścia do prawidłowego katalogu, wskazania konkretnego pliku projektu i sprawdzenia dostępnych wersji SDK. Szczególnie wskazana jest pomoc, gdy nie można ustalić, która instalacja .NET jest aktywna, pliki projektu znikają z katalogu, rozwiązanie działa na innym komputerze, a także wtedy, gdy podobne trudności występują w kilku niezależnych aplikacjach.

Przed przekazaniem sprzętu warto zachować kopię katalogu projektu, pliku global.json, rozwiązania oraz najważniejszych komunikatów z konsoli. Nie należy usuwać plików konfiguracyjnych ani przebudowywać całego rozwiązania bez kopii zapasowej, ponieważ może to utrudnić ustalenie pierwotnej przyczyny. Przydatne będzie także zapisanie informacji o tym, z jakiego katalogu uruchamiano polecenia i czy problem dotyczył kompilacji, przywracania pakietów, czy jedynie automatycznego odnajdywania projektu.

W Warszawie takie przypadki można przekazać do Warszawskiego Pogotowia Komputerowego 24/7, gdzie sprawdzenie środowiska systemowego, ścieżek, instalacji narzędzi i stanu plików pozwala oddzielić błąd konfiguracji od usterki systemu. Naprawy trwają z reguły do 3 dni roboczych, zależnie od zakresu czynności oraz stanu komputera.

Po zakończeniu diagnostyki warto otrzymać jasną informację, co powodowało niewykrywanie projektu, jakie ustawienie zostało zmienione i jak ponownie uruchomić środowisko. Takie podsumowanie ułatwia późniejszą pracę z terminalem, edytorem kodu i rozwiązaniami .NET, a także ogranicza ryzyko powrotu tego samego problemu po aktualizacji narzędzi lub przeniesieniu projektu do innego katalogu.