Install-Module wymaga NuGet mimo jego obecności

Install-Module wymaga NuGet mimo jego obecności wskazuje na nieaktualną wersję dostawcy pakietów — trzeba ją zaktualizować poleceniem Install-PackageProvider NuGet -Force.

Install-Module wymaga NuGet mimo jego obecności — co oznacza ten komunikat

Komunikat informujący, że polecenie Install-Module wymaga dostawcy NuGet mimo jego wcześniejszej instalacji, zwykle nie oznacza całkowitego braku tego komponentu w systemie. W środowisku PowerShell dostawca pakietów może być zainstalowany, lecz nie spełniać wymagań używanej wersji modułu PowerShellGet, bieżącej konfiguracji repozytorium albo ustawień bezpieczeństwa połączenia. W takiej sytuacji system rozpoznaje nazwę NuGet, ale nie potrafi wykorzystać odpowiedniej wersji dostawcy do pobrania i zainstalowania modułu.

Install-Module służy do instalowania modułów PowerShell z repozytorium, najczęściej z galerii PowerShell Gallery. Podczas wykonywania polecenia sprawdzane są między innymi dostępne źródła pakietów, dostawcy PackageManagement, wersje komponentów oraz sposób nawiązywania połączenia z repozytorium. Sam fakt, że NuGet pojawia się na liście dostawców, nie daje pewności, że jego wersja jest aktualna, prawidłowo zarejestrowana i dostępna dla konkretnej sesji PowerShell.

W wielu przypadkach problem można usunąć przez wymuszenie instalacji lub aktualizacji dostawcy:

Install-PackageProvider -Name NuGet -Force

Po wykonaniu polecenia może być potrzebne zamknięcie i ponowne uruchomienie konsoli PowerShell, aby odświeżyć listę dostępnych dostawców oraz załadowane moduły. Następnie można ponowić próbę instalacji, na przykład:

Install-Module -Name NazwaModulu -Scope CurrentUser

Nazwa modułu powinna zostać zastąpiona właściwym identyfikatorem wymaganym w danym środowisku. Warto także sprawdzić, czy używana jest odpowiednia wersja PowerShell oraz czy repozytorium, z którego ma zostać pobrany moduł, jest zarejestrowane i dostępne.

Rola NuGet, PackageManagement i PowerShellGet

NuGet w tym kontekście nie jest pojedynczym modułem przeznaczonym do codziennego używania w konsoli, lecz dostawcą mechanizmu PackageManagement. Odpowiada za obsługę określonego sposobu pobierania pakietów. Z kolei PowerShellGet wykorzystuje mechanizmy PackageManagement podczas wyszukiwania i instalowania modułów PowerShell. Te elementy współpracują ze sobą, ale nie są tym samym składnikiem.

Możliwe jest więc wystąpienie kilku odmiennych sytuacji: NuGet może być zainstalowany pod inną wersją, może znajdować się w lokalizacji niedostępnej dla bieżącego użytkownika, może być widoczny w jednej wersji PowerShell, ale niewidoczny w innej, albo może być zarejestrowany bez wymaganych informacji o źródle. Błąd bywa również powodowany przez starą wersję modułu PowerShellGet lub PackageManagement, która nie interpretuje poprawnie aktualnych wymagań repozytorium.

Przydatne jest sprawdzenie stanu dostawców i modułów za pomocą poleceń:

Get-PackageProvider
Get-Module -ListAvailable PowerShellGet, PackageManagement
Get-PSRepository

Jeżeli repozytorium PowerShell Gallery ma status nieprawidłowy albo nie jest dostępne, sama aktualizacja NuGet może nie wystarczyć. Wtedy analizuje się adres repozytorium, jego rejestrację, ustawienia polityki wykonywania skryptów oraz możliwość nawiązania połączenia HTTPS. W środowisku, w którym występują różne instalacje PowerShell, należy zwrócić uwagę na to, z której konsoli uruchamiane są polecenia, ponieważ każda wersja może korzystać z innego zestawu modułów i lokalizacji użytkownika.

W nowszych środowiskach może być dostępny także PowerShellGet drugiej generacji, oparty na rozwiązaniu PSResourceGet. W takim przypadku używane polecenia oraz sposób zarządzania źródłami pakietów mogą się różnić. Nie należy bez sprawdzenia mieszać instrukcji przeznaczonych dla różnych mechanizmów, ponieważ może to prowadzić do kolejnych komunikatów o brakujących dostawcach, źródłach lub uprawnieniach.

Typowe przyczyny błędu i powiązane objawy

Jedną z częstszych przyczyn jest uruchomienie PowerShell bez uprawnień pozwalających na zapis w systemowej lokalizacji modułów. W takiej sytuacji można użyć zakresu instalacji dla bieżącego użytkownika, na przykład -Scope CurrentUser, o ile polityka obowiązująca w danym środowisku na to pozwala. Innym rozwiązaniem jest uruchomienie konsoli z odpowiednimi uprawnieniami, jednak przed zmianą uprawnień powinno się ustalić, gdzie faktycznie ma zostać zapisany dostawca lub moduł.

Problem może pojawić się również wtedy, gdy system korzysta z ograniczonego protokołu TLS, nieaktualnych certyfikatów albo filtruje połączenia z repozytorium. W takim przypadku komunikat o NuGet może być tylko objawem problemu z dostępem do źródła pakietów. Warto odróżnić sytuację, w której dostawca nie jest zainstalowany, od sytuacji, w której jest zainstalowany, lecz nie można pobrać metadanych lub archiwum modułu.

Do podobnych błędów prowadzą także:

• niezgodna lub bardzo stara wersja PowerShellGet;
• uszkodzone wpisy dostawcy w lokalnym profilu użytkownika;
• kilka instalacji PowerShell korzystających z odmiennych ścieżek modułów;
• repozytorium oznaczone jako niezaufane albo nieprawidłowo zarejestrowane;
• brak dostępu do Internetu, serwera proxy lub firmowego serwera pośredniczącego;
• blokada połączenia przez oprogramowanie ochronne lub reguły zapory;
• konflikt wersji między modułami zainstalowanymi systemowo i lokalnie.

Jeżeli polecenie Install-PackageProvider -Name NuGet -Force kończy się błędem, nie powinno się bezrefleksyjnie usuwać wszystkich modułów ani kasować katalogów systemowych. Najpierw należy odczytać pełny komunikat, sprawdzić lokalizację instalacji oraz wykonać test rozpoznawania dostawcy. Usunięcie niewłaściwego składnika może doprowadzić do problemów z innymi modułami PowerShell, skryptami administracyjnymi lub automatyzacją działającą na tym samym koncie.

Warto również zachować informację o wersji systemu, wydaniu PowerShell, używanym koncie oraz dokładnej treści błędu. Pozwala to ustalić, czy przyczyną jest brak aktualizacji, problem z uprawnieniami, niedostępne repozytorium czy niespójność lokalnej konfiguracji.

Kiedy trzeba zgłosić sprzęt do serwisu - Install-Module wymaga NuGet mimo jego obecności

Do serwisu warto zgłosić się wtedy, gdy aktualizacja NuGet nie przynosi rezultatu, komunikaty zmieniają się po każdym uruchomieniu konsoli albo problem występuje równocześnie z innymi objawami, takimi jak błędy instalacji aplikacji, niedziałające aktualizacje lub problemy z połączeniem z repozytoriami. Szczególnej ostrożności wymaga sytuacja, w której PowerShell jest wykorzystywany do obsługi ważnych skryptów, kopii zapasowych lub automatycznych zadań systemowych, ponieważ przypadkowa zmiana ścieżek modułów może zakłócić ich działanie.

W Warszawie takie przypadki można przekazać do Warszawskiego Pogotowia Komputerowego 24/7, gdzie analizowany jest stan środowiska PowerShell, dostępność repozytoriów, wersje dostawców oraz uprawnienia użytkownika. Dla laptopa przewidziana jest darmowa diagnoza LAPTOPA, co pozwala najpierw ustalić źródło problemu bez pochopnego usuwania składników systemu.

Podczas zgłoszenia przydatne jest przekazanie dokładnego polecenia, które wywołuje błąd, pełnego wyniku z konsoli oraz informacji o tym, czy używany jest Windows PowerShell, czy PowerShell w nowszym wydaniu. Jeżeli problem pojawia się tylko na jednym koncie, należy zaznaczyć ten fakt, ponieważ może wskazywać na uszkodzenie profilu użytkownika lub lokalną konfigurację modułów. Jeżeli występuje na wielu kontach albo na kilku urządzeniach, większe znaczenie może mieć konfiguracja sieci, repozytorium lub wspólna polityka bezpieczeństwa.

Po prawidłowej naprawie powinno być możliwe rozpoznanie dostawcy NuGet, odczytanie dostępnego repozytorium oraz zainstalowanie wymaganego modułu bez ponownego komunikatu o braku dostawcy. Zalecane jest również sprawdzenie, czy rozwiązanie działa po ponownym uruchomieniu PowerShell i czy nie narusza działania wcześniej używanych modułów.