Instalowanie modułu programu PowerShell
Po utworzeniu modułu programu PowerShell prawdopodobnie konieczne będzie zainstalowanie modułu w systemie, aby można było go używać przez Ciebie lub inne osoby. Ogólnie rzecz biorąc, polega to na skopiowaniu plików modułu (tj. psm1 lub zestawu binarnego, manifestu modułu i innych skojarzonych plików) do katalogu na tym komputerze. W przypadku bardzo małego projektu może to być tak proste jak skopiowanie i wklejenie plików za pomocą eksploratora Windows na jednym komputerze zdalnym; Jednak w przypadku większych rozwiązań warto użyć bardziej zaawansowanego procesu instalacji. Niezależnie od sposobu, w jaki moduł jest dostępny w systemie, program PowerShell może korzystać z wielu technik, które umożliwiają użytkownikom znajdowanie modułów i korzystanie z nich. Dlatego głównym problemem podczas instalacji jest zapewnienie, że program PowerShell będzie mógł znaleźć moduł. Aby uzyskać więcej informacji, zobacz Importowanie modułu programu PowerShell.
Reguły instalowania modułów
Poniższe informacje odnoszą się do wszystkich modułów, w tym modułów tworzyć na własny użytek, modułów, które można uzyskać od innych podmiotów, oraz modułów dystrybuowanych do innych osób.
Instalowanie modułów w programie PSModulePath
Jeśli to możliwe, zainstaluj wszystkie moduły w ścieżce wymienionej w zmiennej środowiskowej PSModulePath lub dodaj ścieżkę modułu do wartości zmiennej środowiskowej PSModulePath.
Zmienna środowiskowa PSModulePath ( ) zawiera lokalizacje Windows PowerShell $Env:PSModulePath modułów. Polecenia cmdlet polegają na wartości tej zmiennej środowiskowej w celu znalezienia modułów.
Domyślnie wartość zmiennej środowiskowej PSModulePath zawiera następujące katalogi systemu i modułu użytkownika, ale można dodawać i edytować wartość.
$PSHome\Modules(%Windir%\System32\WindowsPowerShell\v1.0\Modules)Ostrzeżenie
Ta lokalizacja jest zarezerwowana dla modułów, które są Windows. Nie instaluj modułów w tej lokalizacji.
$Home\Documents\WindowsPowerShell\Modules(%UserProfile%\Documents\WindowsPowerShell\Modules)$Env:ProgramFiles\WindowsPowerShell\Modules(%ProgramFiles%\WindowsPowerShell\Modules)Aby uzyskać wartość zmiennej środowiskowej PSModulePath, użyj jednego z następujących poleceń.
$Env:PSModulePath [Environment]::GetEnvironmentVariable("PSModulePath")Aby dodać ścieżkę modułu do wartości zmiennej środowiskowej PSModulePath, użyj następującego formatu polecenia. Ten format używa metody SetEnvironmentVariable klasy System.Environment, aby wprowadzić niezależną od sesji zmianę zmiennej środowiskowej PSModulePath.
#Save the current value in the $p variable. $p = [Environment]::GetEnvironmentVariable("PSModulePath") #Add the new path to the $p variable. Begin with a semi-colon separator. $p += ";C:\Program Files (x86)\MyCompany\Modules\" #Add the paths in $p to the PSModulePath value. [Environment]::SetEnvironmentVariable("PSModulePath",$p)Ważne
Po dodaniu ścieżki do ścieżki PSModulePath należy rozgłaszać komunikat środowiska o zmianie. Emisja zmiany umożliwia innym aplikacjom, takim jak powłoka, odebranie zmiany. Aby rozgłaszać zmianę, kod instalacji produktu musi wysłać komunikat WM_SETTINGCHANGE z ciągiem
lParam"Environment". Pamiętaj, aby wysłać komunikat po zaktualizowaniu psmodulePath kodu instalacji modułu.
Użyj poprawnej nazwy katalogu modułu
Dobrze uformowany moduł to moduł przechowywany w katalogu, który ma taką samą nazwę jak nazwa podstawowa co najmniej jednego pliku w katalogu modułu. Jeśli moduł nie jest dobrze uformowany, Windows PowerShell nie rozpoznaje go jako modułu.
"Nazwa podstawowa" pliku to nazwa bez rozszerzenia nazwy pliku. W dobrze formularzowym module nazwa katalogu zawierającego pliki modułu musi być taka sama jak nazwa podstawowa co najmniej jednego pliku w module.
Na przykład w przykładowym module Firmy Fabrikam katalog zawierający pliki modułów ma nazwę "Fabrikam", a co najmniej jeden plik ma podstawową nazwę "Fabrikam". W tym przypadku zarówno fabrikam.psd1, jak i Fabrikam.dll mają podstawową nazwę "Fabrikam".
C:\Program Files
Fabrikam Technologies
Fabrikam Manager
Modules
Fabrikam
Fabrikam.psd1 (module manifest)
Fabrikam.dll (module assembly)
Efekt nieprawidłowej instalacji
Jeśli moduł nie jest dobrze uformowany, a jego lokalizacja nie jest uwzględniona w wartości zmiennej środowiskowej PSModulePath, podstawowe funkcje odnajdywania modułu Windows PowerShell, takie jak poniższe, nie działają.
Funkcja automatycznego ładowania modułów nie może zaimportować modułu automatycznie.
Parametr
ListAvailablepolecenia cmdlet Get-Module nie może odnaleźć modułu.Polecenie cmdlet Import-Module nie może odnaleźć modułu. Aby zaimportować moduł, musisz podać pełną ścieżkę do pliku głównego modułu lub pliku manifestu modułu.
Dodatkowe funkcje, takie jak poniższe, nie działają, chyba że moduł zostanie zaimportowany do sesji. W dobrze uformowanych modułach w zmiennej środowiskowej PSModulePath te funkcje działają nawet wtedy, gdy moduł nie jest importowany do sesji.
Polecenie cmdlet Get-Command nie może znaleźć poleceń w module .
Polecenia cmdlet Update-Help i Save-Help nie mogą aktualizować ani zapisywać pomocy dotyczącej modułu.
Polecenie cmdlet Show-Command nie może znaleźć i wyświetlić poleceń w module .
Brakuje poleceń w oknie w
Show-Commandśrodowisku Windows PowerShell Scripting Environment (ISE).
Gdzie instalować moduły
W tej sekcji wyjaśniono, gdzie w systemie plików zainstalować Windows PowerShell modułów. Lokalizacja zależy od sposobu, w jaki jest używany moduł.
Instalowanie modułów dla określonego użytkownika
Jeśli utworzysz własny moduł lub pobierzesz moduł od innej firmy, takiej jak witryna internetowa społeczności usługi Windows PowerShell, i chcesz, aby moduł był dostępny tylko dla Twojego konta użytkownika, zainstaluj moduł w katalogu Modules specyficznym dla użytkownika.
$home\Documents\WindowsPowerShell\Modules\<Module Folder>\<Module Files>
Katalog Modules specyficzny dla użytkownika jest domyślnie dodawany do wartości zmiennej środowiskowej PSModulePath.
Instalowanie modułów dla wszystkich użytkowników w programie Program Files
Jeśli chcesz, aby moduł był dostępny dla wszystkich kont użytkowników na komputerze, zainstaluj moduł w lokalizacji Program Files.
$Env:ProgramFiles\WindowsPowerShell\Modules\<Module Folder>\<Module Files>
Uwaga
Lokalizacja Program Files jest domyślnie dodawana do wartości zmiennej środowiskowej PSModulePath w Windows PowerShell 4.0 i nowszych. W przypadku wcześniejszych wersji programu Windows PowerShell można ręcznie utworzyć lokalizację programu Program Files (%ProgramFiles%\WindowsPowerShell\Modules) i dodać tę ścieżkę do zmiennej środowiskowej PSModulePath zgodnie z powyższym opisem.
Instalowanie modułów w katalogu produktów
Jeśli dystrybuujesz moduł do innych firm, użyj domyślnej lokalizacji Program Files opisanej powyżej lub utwórz własny podkatalog specyficzny dla firmy lub produktu w katalogu %ProgramFiles%.
Na przykład fikcyjna firma Fabrikam Technologies wysyła moduł Windows PowerShell produktu Fabrikam Manager. Instalator modułu tworzy podkatalog Modules w podkatalogu produktu Fabrikam Manager.
C:\Program Files
Fabrikam Technologies
Fabrikam Manager
Modules
Fabrikam
Fabrikam.psd1 (module manifest)
Fabrikam.dll (module assembly)
Aby włączyć Windows PowerShell odnajdywania modułów w celu znalezienia modułu Fabrikam, instalator modułu Firmy Fabrikam dodaje lokalizację modułu do wartości zmiennej środowiskowej PSModulePath.
$p = [Environment]::GetEnvironmentVariable("PSModulePath")
$p += ";C:\Program Files\Fabrikam Technologies\Fabrikam Manager\Modules\"
[Environment]::SetEnvironmentVariable("PSModulePath",$p)
Instalowanie modułów w katalogu Common Files
Jeśli moduł jest używany przez wiele składników produktu lub przez wiele wersji produktu, zainstaluj moduł w podkatalogu %ProgramFiles%\Common Files\Modules.
W poniższym przykładzie moduł Firmy Fabrikam jest instalowany w podkatalogu firmy Fabrikam %ProgramFiles%\Common Files\Modules podkatalogu. Należy pamiętać, że każdy moduł znajduje się we własnym podkatalogu w podkatalogu Modules.
C:\Program Files
Common Files
Modules
Fabrikam
Fabrikam.psd1 (module manifest)
Fabrikam.dll (module assembly)
Następnie instalator zapewnia wartość zmiennej środowiskowej PSModulePath, która zawiera ścieżkę podkatalogu wspólnych modułów plików.
$m = $env:ProgramFiles + '\Common Files\Modules'
$p = [Environment]::GetEnvironmentVariable("PSModulePath")
$q = $p -split ';'
if ($q -notContains $m) {
$q += ";$m"
}
$p = $q -join ';'
[Environment]::SetEnvironmentVariable("PSModulePath", $p)
Instalowanie wielu wersji modułu
Aby zainstalować wiele wersji tego samego modułu, użyj poniższej procedury.
- Utwórz katalog dla każdej wersji modułu. Dołącz numer wersji w nazwie katalogu.
- Utwórz manifest modułu dla każdej wersji modułu. W wartości klucza ModuleVersion w manifeście wprowadź numer wersji modułu. Zapisz plik manifestu (psd1) w katalogu specyficznym dla wersji modułu.
- Dodaj ścieżkę folderu głównego modułu do wartości zmiennej środowiskowej PSModulePath, jak pokazano w poniższych przykładach.
Aby zaimportować określoną wersję modułu, użytkownik końcowy może użyć parametrów lub polecenia MinimumVersion RequiredVersion cmdlet Import-Module.
Jeśli na przykład moduł Fabrikam jest dostępny w wersjach 8.0 i 9.0, struktura katalogów modułu Fabrikam może wyglądać następująco.
C:\Program Files
Fabrikam Manager
Fabrikam8
Fabrikam
Fabrikam.psd1 (module manifest: ModuleVersion = "8.0")
Fabrikam.dll (module assembly)
Fabrikam9
Fabrikam
Fabrikam.psd1 (module manifest: ModuleVersion = "9.0")
Fabrikam.dll (module assembly)
Instalator dodaje obie ścieżki modułów do wartości zmiennej środowiskowej PSModulePath.
$p = [Environment]::GetEnvironmentVariable("PSModulePath")
$p += ";C:\Program Files\Fabrikam\Fabrikam8;C:\Program Files\Fabrikam\Fabrikam9"
[Environment]::SetEnvironmentVariable("PSModulePath",$p)
Po zakończeniu tych kroków parametr ListAvailable polecenia cmdlet Get-Module pobiera oba moduły Fabrikam. Aby zaimportować określony moduł, użyj parametrów lub polecenia MinimumVersion RequiredVersion cmdlet Import-Module.
Jeśli oba moduły są importowane do tej samej sesji, a moduły zawierają polecenia cmdlet o takich samych nazwach, polecenia cmdlet, które są importowane jako ostatnie, są skuteczne w sesji.
Obsługa konfliktów nazw poleceń
Konflikty nazw poleceń mogą wystąpić, gdy polecenia eksportowane przez moduł mają taką samą nazwę jak polecenia w sesji użytkownika.
Gdy sesja zawiera dwa polecenia, które mają taką samą Windows PowerShell uruchamia typ polecenia, który ma pierwszeństwo. Gdy sesja zawiera dwa polecenia, które mają taką samą nazwę i ten sam typ, Windows PowerShell uruchamia polecenie, które zostało ostatnio dodane do sesji. Aby uruchomić polecenie, które nie jest uruchamiane domyślnie, użytkownicy mogą kwalifikować nazwę polecenia przy użyciu nazwy modułu.
Jeśli na przykład sesja zawiera funkcję i Get-Date polecenie Get-Date cmdlet , Windows PowerShell domyślnie uruchamia funkcję. Aby uruchomić polecenie cmdlet, należy poprzeć polecenie nazwą modułu, taką jak:
Microsoft.PowerShell.Utility\Get-Date
Aby zapobiec konfliktom nazw, autorzy modułów mogą użyć klucza DefaultCommandPrefix w manifeście modułu, aby określić prefiks rzeczownika dla wszystkich poleceń wyeksportowanych z modułu.
Użytkownicy mogą używać prefiksu parametru Import-Module polecenia cmdlet, aby użyć alternatywnego prefiksu. Wartość parametru Prefix ma pierwszeństwo przed wartością klucza DefaultCommandPrefix.
Ścieżki obsługi w systemach innych Windows spoza systemu
Platformy Windows używają znaku dwukropka () jako separatora ścieżki i ukośnika : / () jako separatora katalogów. Klasa ma statyczne składowe, których można użyć do działania kodu [System.IO.Path] na dowolnej platformie:
[System.IO.Path]::PathSeparator— zwraca znak używany do oddzielania ścieżek w zmiennej środowiskowej PATH dla platformy hosta[System.IO.Path]::DirectorySeparatorChar— zwraca znak używany do oddzielania nazw katalogów ścieżką dla platformy hosta
Użyj tych właściwości statycznych, aby w miejsce znaków ; i \ podczas konstruowania ciągów ścieżek.
Zobacz też
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla