Visual Studio nierozpoznające frameworka wskazuje na brak zainstalowanego docelowego SDK zdefiniowanego w pliku projektu.
Co oznacza komunikat o nierozpoznanym frameworku
Komunikat informujący, że Visual Studio nie rozpoznaje frameworka, najczęściej oznacza, że środowisko nie może odnaleźć zestawu SDK wymaganego przez projekt. W projektach .NET docelowa platforma jest określana właściwością TargetFramework albo TargetFrameworks w pliku projektu, na przykład jako net8.0, net7.0 lub netstandard2.0. Taki zapis nie instaluje frameworka automatycznie. Wskazuje jedynie, z jaką platformą i zestawem referencji projekt ma być kompilowany.
Trzeba rozróżnić trzy elementy: SDK, runtime i framework referencyjny. .NET SDK zawiera narzędzia kompilacji, MSBuild oraz pliki potrzebne do budowania projektu. Runtime pozwala uruchamiać gotowe aplikacje, ale zwykle nie wystarcza do ich kompilowania. Framework referencyjny dostarcza opisy bibliotek używanych przez kompilator. Zainstalowany sam runtime może więc umożliwiać uruchomienie programu, a jednocześnie nie rozwiązywać problemu z budowaniem projektu w Visual Studio.
TargetFramework, plik projektu i wybór zestawu SDK
Pierwszym miejscem do sprawdzenia jest plik projektu z rozszerzeniem .csproj, .vbproj albo innym właściwym dla używanego języka. W projekcie opartym na SDK można znaleźć wpis podobny do <TargetFramework>net8.0</TargetFramework>. Jeżeli wskazany moniker nie odpowiada zainstalowanym komponentom, Visual Studio może oznaczyć framework jako nierozpoznany, nie załadować projektu prawidłowo albo zgłosić błąd podczas przywracania pakietów.
Znaczenie ma także plik global.json, jeśli znajduje się w katalogu projektu lub w jednym z jego katalogów nadrzędnych. Ten plik może wymuszać konkretną wersję SDK za pomocą właściwości version. W takiej sytuacji obecność nowszego SDK nie zawsze wystarcza, ponieważ narzędzia próbują użyć wersji wskazanej w konfiguracji. Warto sprawdzić, czy wymagana wersja jest zainstalowana oraz czy ustawienie rollForward nie ogranicza możliwości użycia innej wersji zgodnej z regułami danego projektu.
Sprawdzenie instalacji bez zgadywania
Listę SDK dostępnych w systemie można sprawdzić poleceniem dotnet --list-sdks, a listę zainstalowanych środowisk uruchomieniowych poleceniem dotnet --list-runtimes. Wynik pierwszego polecenia pozwala porównać faktycznie zainstalowane wersje z wartością określoną w TargetFramework oraz ewentualnie w global.json. Polecenie dotnet --info pokazuje dodatkowo używany katalog instalacyjny, wersję hosta i informacje o środowisku.
Jeżeli SDK jest zainstalowane, ale Visual Studio nadal nie rozpoznaje frameworka, należy sprawdzić instalację programu Visual Studio Installer. Dla projektów .NET wymagane mogą być odpowiednie workloady, składniki indywidualne oraz developer pack lub targeting pack dla starszych technologii .NET Framework. .NET Framework i nowoczesny .NET, oznaczany między innymi jako net6.0 czy net8.0, nie są tym samym produktem i korzystają z odmiennych pakietów instalacyjnych. Dla projektu przeznaczonego dla .NET Framework nie wystarczy zainstalowanie SDK nowoczesnego .NET.
Po zmianie składników instalacji trzeba ponownie uruchomić Visual Studio, a następnie wykonać przywracanie zależności projektu. W przypadku projektu SDK-style można użyć polecenia dotnet restore. Jeżeli problem dotyczy uszkodzonego lub nieaktualnego stanu przywracania, pomocne bywa usunięcie katalogu obj i ponowne wygenerowanie plików po zamknięciu środowiska. Nie należy jednak usuwać plików projektu ani zmieniać docelowego frameworka bez sprawdzenia wymagań aplikacji i zależności NuGet.
Naprawa konfiguracji Visual Studio i projektu
Jeżeli projekt wskazuje framework, którego nie można już zainstalować w używanej konfiguracji, rozwiązaniem może być aktualizacja Visual Studio albo dostosowanie projektu do wersji obsługiwanej przez jego narzędzia. Taka zmiana wymaga sprawdzenia plików zależności, pakietów NuGet, ustawień kompilacji oraz bibliotek używanych przez aplikację. Samo zastąpienie wartości TargetFramework innym monikerem może prowadzić do błędów kompilacji, niezgodności API albo zmiany zachowania programu.
Diagnostyka powinna obejmować dokładny tekst błędu, lokalizację pliku .csproj, zawartość ewentualnego global.json, wynik poleceń dotyczących SDK oraz informacje o edycji i zainstalowanych składnikach Visual Studio. Trzeba również sprawdzić, czy Visual Studio i polecenie dotnet korzystają z tej samej instalacji narzędzi. Po usunięciu rozbieżności wykonuje się ponowne ładowanie rozwiązania, przywracanie pakietów i kompilację. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC oraz ich podzespołów, w tym diagnostyką problemów z instalacją i konfiguracją popularnego oprogramowania używanego na tych urządzeniach.
