PowerShell Core nie widzi modułów z PS 5

PowerShell Core niewidzące modułów z PS 5 wskazuje na różnice w architekturze modułów między Windows PowerShell 5.1 a wieloplatformowym PowerShell 7+.

PowerShell Core nie widzi modułów z PS 5 – czym różnią się obie generacje

Problem opisany jako „PowerShell Core nie widzi modułów z PS 5” wynika najczęściej z tego, że PowerShell 7+ oraz Windows PowerShell 5.1 korzystają z odmiennych środowisk uruchomieniowych. Windows PowerShell 5.1 został zaprojektowany dla platformy .NET Framework i przez lata był dostarczany razem z systemem Windows. PowerShell Core, a następnie PowerShell 7+, działa na nowszej, wieloplatformowej platformie .NET. Sama obecność katalogu modułu na dysku nie oznacza więc, że każda jego funkcja będzie dostępna w aktualnie uruchomionej powłoce.

W praktyce moduł może być zainstalowany poprawnie, a mimo to polecenie Get-Module -ListAvailable nie pokaże go na liście. Przyczyną bywa inna ścieżka wyszukiwania, niezgodna wersja środowiska, zależność od bibliotek dostępnych wyłącznie w Windows albo ograniczenie wynikające z użycia starszego modelu modułu. Należy też rozróżnić brak modułu od braku konkretnego polecenia. Moduł może zostać znaleziony, lecz nie załadować się podczas importu.

PowerShell Core nie widzi modułów z PS 5 – kontekst techniczny i porównanie

Windows PowerShell 5.1 i PowerShell 7+ mogą być zainstalowane na tym samym komputerze, ale nie tworzą jednego wspólnego środowiska. Każda z powłok ma własne zmienne, własne ścieżki modułów oraz odrębny sposób obsługi zależności. Moduł dodany poleceniem uruchomionym w jednej wersji nie zawsze jest instalowany w lokalizacji, którą automatycznie przeszukuje druga wersja.

Podstawowym punktem porównania jest zmienna $env:PSModulePath. Zawiera ona listę katalogów oddzielonych średnikami w systemie Windows i dwukropkami w systemach uniksowych. Jeśli katalog z modułem nie występuje na tej liście, mechanizm automatycznego wyszukiwania go nie uwzględni. Do sprawdzenia ścieżek można użyć polecenia $env:PSModulePath -split [IO.Path]::PathSeparator, a następnie porównać wynik z lokalizacją folderu zawierającego plik manifestu .psd1 lub skrypt modułu .psm1.

Istotna jest także właściwość CompatiblePSEditions w manifeście modułu. Wartość Desktop wskazuje zwykle na przeznaczenie dla Windows PowerShell, natomiast Core oznacza zgodność z PowerShell Core. Wpis Desktop nie zawsze blokuje próbę importu, lecz sygnalizuje, że autor mógł wykorzystać elementy niedostępne w PowerShell 7+. Moduł wieloplatformowy może natomiast wymagać nowszej wersji określonego pakietu albo dodatkowej biblioteki.

Ważny jest również sposób instalacji. Polecenie Install-Module zapisuje moduły w lokalizacji zależnej od zakresu instalacji, konta użytkownika oraz użytego dostawcy pakietów. Instalacja wykonana bezpośrednio w Windows PowerShell 5.1 może trafić do katalogu widocznego tylko dla tej powłoki. Dla PowerShell 7+ należy sprawdzić, czy instalacja została przeprowadzona z właściwego programu, a nie jedynie z tego samego skrótu lub okna, które przypadkowo uruchamia starszą wersję.

PowerShell Core nie widzi modułów z PS 5 – typowe problemy z importem

Jednym z częstych przypadków jest umieszczenie modułu w katalogu o podobnej nazwie, lecz innym poziomie zagnieżdżenia. PowerShell oczekuje zazwyczaj struktury, w której folder modułu zawiera plik .psd1 albo .psm1. Jeżeli archiwum zostało rozpakowane do dodatkowego podfolderu, wyszukiwanie może zakończyć się niepowodzeniem. Pomocne jest ręczne wskazanie ścieżki, na przykład Import-Module -Name C:\Sciezka\Modul\Modul.psd1 -Verbose, przy czym należy zastosować rzeczywistą lokalizację z danego komputera.

Drugi przypadek to moduły oparte na poleceniach i bibliotekach dostępnych wyłącznie w Windows PowerShell 5.1. Mogą one korzystać z komponentów związanych ze starszym środowiskiem .NET, określonych mechanizmów rejestru, usług systemowych lub bibliotek natywnych. Wtedy komunikat może mówić o braku typu, biblioteki albo metody, mimo że folder modułu został odnaleziony. Nie jest to problem samej ścieżki, ale niezgodności zależności.

Trudności powoduje także wersja modułu. W jednym z katalogów może znajdować się starsza edycja, a w innym nowsza. Polecenie Get-Module -ListAvailable -Name NazwaModulu pozwala sprawdzić, czy dostępnych jest kilka wydań. Przydatne są również Get-Module -Name NazwaModulu -ListAvailable | Select-Object Name,Version,Path oraz Get-Command -Module NazwaModulu. Dzięki nim można ustalić, czy problem dotyczy odnalezienia modułu, jego zaimportowania czy dopiero braku oczekiwanego polecenia.

Niektóre moduły są dostarczane jako część narzędzi producenta i nie powinny być kopiowane ręcznie między komputerami. Samo przeniesienie folderu może pominąć zależności, wpisy konfiguracyjne lub wymagane składniki. Bezpieczniejszym podejściem jest użycie oficjalnego repozytorium, właściwej wersji instalatora albo dokumentacji autora. Warto też zwrócić uwagę na komunikaty generowane przez Import-Module -Verbose, ponieważ często wskazują dokładny plik, który nie może zostać załadowany.

PowerShell Core nie widzi modułów z PS 5 – praktyczne wskazówki diagnostyczne

Diagnozę można rozpocząć od ustalenia, jaka powłoka rzeczywiście działa. Polecenie $PSVersionTable pokazuje między innymi nazwę i numer wersji środowiska. Następnie warto wykonać Get-Module -ListAvailable oraz sprawdzić $env:PSModulePath. Te trzy informacje często wystarczają, aby odróżnić uruchomienie Windows PowerShell 5.1 od PowerShell 7+ i wykryć brak właściwej lokalizacji w ścieżce.

Kolejny etap powinien obejmować próbę jawnego importu z pełną ścieżką. Jeżeli import zadziała, przyczyną jest najprawdopodobniej konfiguracja PSModulePath albo nieprawidłowa struktura katalogów. Jeżeli pojawi się błąd zależności, należy odczytać jego pełną treść, a nie tylko pierwszą linię. W wielu sytuacjach komunikat wskazuje nazwę brakującej biblioteki, wymaganą wersję albo funkcję niedostępną w aktualnym środowisku.

Przydatne bywa sprawdzenie manifestu modułu poleceniem Test-ModuleManifest. Pozwala ono wykryć błędy składniowe, nieistniejące pliki zagnieżdżone i niezgodności deklarowane w pliku manifestu. Warto również zweryfikować politykę wykonywania skryptów, podpis cyfrowy oraz blokadę pliku pobranego z internetu. Te ustawienia mogą uniemożliwić załadowanie modułu, lecz zwykle powodują inny rodzaj komunikatu niż całkowity brak modułu na liście.

Jeżeli moduł przeznaczony jest wyłącznie dla Windows PowerShell 5.1, rozsądnym rozwiązaniem może być uruchomienie go w starszej powłoce, o ile producent nie udostępnia wersji zgodnej z PowerShell 7+. Nie należy zastępować plików systemowych ani kopiować bibliotek metodą prób i błędów. Przydatne jest zapisanie wersji systemu, wersji obu powłok, wyniku $env:PSModulePath oraz pełnego komunikatu błędu. Taki zestaw danych ułatwia odtworzenie problemu i ogranicza ryzyko zmiany konfiguracji bez kontroli.

PowerShell Core nie widzi modułów z PS 5 – kiedy zgłosić się do serwisu

Do serwisu warto zgłosić się wtedy, gdy moduł jest potrzebny do pracy, a kolejne próby instalacji zmieniają widoczność poleceń lub powodują błędy w innych skryptach. Szczególnej ostrożności wymaga sytuacja, w której na komputerze znajdują się jednocześnie różne wersje PowerShell, kilka kont użytkowników albo moduły instalowane przez różne programy. Wtedy przyczyną może być nie tylko brak folderu na ścieżce, ale również niespójna konfiguracja środowiska, uprawnienia do katalogu lub uszkodzona instalacja składnika.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się analizą takich problemów na komputerach z systemem Windows, sprawdzając wersję powłoki, lokalizacje modułów, manifesty i komunikaty importu. Przed przekazaniem sprzętu warto przygotować nazwę modułu, polecenie wywołujące błąd, wynik $PSVersionTable oraz informację, czy ten sam moduł działa w Windows PowerShell 5.1. Pozwala to szybciej rozdzielić problem z instalacją od ograniczenia zgodności samego modułu i dobrać rozwiązanie niewymagające przypadkowego usuwania działających elementów.