Visual Studio nie widzi zainstalowanego .NET Framework

Visual Studio niewidzące zainstalowanego .NET Framework wskazuje na uszkodzony wpis rejestru komponentów w gałęzi NDP.

Jak Visual Studio rozpoznaje zainstalowany .NET Framework

Visual Studio nie ustala obecności .NET Framework wyłącznie na podstawie wpisu na liście zainstalowanych programów. Przy wyborze docelowej platformy sprawdzane są między innymi wpisy rejestru Windows oraz dostępność odpowiednich plików referencyjnych. Dla .NET Framework 4.5 i nowszych podstawowym miejscem identyfikacji jest gałąź HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full. Wartość Install informuje, czy pełny składnik został zainstalowany, a wartość Release pozwala określić poziom wydania.

W starszych wersjach .NET Framework informacje są przechowywane w podkluczach odpowiadających konkretnym wersjom, między innymi v2.0.50727 oraz v3.5. Sam fakt znalezienia wpisu dotyczącego wersji 4.x nie oznacza jednak, że Visual Studio ma dostęp do plików potrzebnych do kompilacji projektu. Środowisko programistyczne korzysta także z zestawu targeting pack, czyli pakietu docelowego zawierającego referencje i metadane używane podczas budowania aplikacji.

Różnica między środowiskiem uruchomieniowym a targeting packiem

Najczęstszą przyczyną pozornego braku .NET Framework jest pomylenie dwóch składników. Runtime umożliwia uruchamianie aplikacji, natomiast targeting pack jest potrzebny do tworzenia projektu przeznaczonego dla określonej wersji frameworka. Komputer może więc poprawnie uruchamiać program napisany dla .NET Framework 4.8, a jednocześnie nie mieć zainstalowanych plików referencyjnych wymaganych przez projekt ustawiony na konkretną wersję docelową.

Pliki referencyjne są zwykle umieszczane w katalogu Reference Assemblies\Microsoft\Framework\.NETFramework w obrębie katalogu plików programów, często w jego 32-bitowej lokalizacji. Jeżeli brakuje podkatalogu odpowiadającego wersji projektu, Visual Studio może wyświetlić komunikat o niedostępnym frameworku albo oznaczyć platformę jako niezainstalowaną. Dotyczy to również sytuacji, w której wpis rejestru istnieje, ale instalacja pakietu docelowego została uszkodzona lub usunięta podczas aktualizacji środowiska.

Wpis NDP, architektura systemu i uszkodzona instalacja

Gałąź NDP może zawierać prawidłowe dane dla jednej architektury rejestru, podczas gdy narzędzie odczytuje inną jego perspektywę. W systemie 64-bitowym część aplikacji korzysta z widoku 32-bitowego, powiązanego z mechanizmem WOW64. Dlatego podczas analizy nie wystarczy sprawdzić przypadkowego klucza o podobnej nazwie. Należy potwierdzić, czy odczyt dotyczy właściwej gałęzi, właściwego podklucza oraz właściwych wartości Install i Release.

Uszkodzenie wpisu NDP może powstać po przerwanym odinstalowaniu, nieudanej aktualizacji, ręcznym czyszczeniu rejestru albo przywróceniu części plików systemowych z kopii. Objawem bywa rozbieżność między informacją systemu a zachowaniem Visual Studio: system wskazuje zainstalowany .NET Framework, ale lista platform docelowych nie zawiera wymaganej wersji. Diagnostyka powinna wtedy obejmować nie tylko rejestr, lecz także katalogi referencyjne, konfigurację projektu, zainstalowane komponenty Visual Studio oraz logi instalatora. Nie należy ręcznie dopisywać wartości do NDP bez ustalenia, czy odpowiadają rzeczywiście zainstalowanym plikom.

Naprawa wykrywania frameworka w środowisku programistycznym

Postępowanie zależy od wyniku weryfikacji. Jeżeli brakuje wyłącznie plików deweloperskich, właściwym rozwiązaniem jest doinstalowanie odpowiedniego .NET Framework Developer Pack albo targeting pack za pośrednictwem instalatora Visual Studio lub oficjalnego instalatora Microsoft. Jeżeli problem dotyczy samego Visual Studio, można użyć funkcji Modify do ponownego zaznaczenia wymaganych komponentów, a w przypadku uszkodzenia instalacji także funkcji Repair. Po zmianach należy ponownie uruchomić środowisko i sprawdzić, czy projekt wskazuje właściwy framework docelowy.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów i komputerów PC, w tym diagnostyką problemów z instalacją systemu Windows, komponentami .NET Framework oraz środowiskiem Visual Studio. W praktyce analiza obejmuje rozróżnienie braku runtime od braku targeting packa, kontrolę wpisów NDP, sprawdzenie zgodności architektury rejestru i ocenę integralności plików referencyjnych. Takie podejście ogranicza ryzyko pozornej naprawy, w której rejestr zostaje zmieniony, ale Visual Studio nadal nie ma plików wymaganych do kompilacji.