about_PowerShell_Editions
Kurze Beschreibung
Verschiedene Editionen von PowerShell werden auf verschiedenen zugrunde liegenden Runtimes ausgeführt.
Lange Beschreibung
Ab PowerShell 5.1 gibt es mehrere Editionen von PowerShell, die jeweils auf einer anderen .NET-Runtime ausgeführt werden. Ab PowerShell 6.0 gibt es zwei Editionen von PowerShell:
- Desktop, der auf .NET Framework ausgeführt wird. PowerShell 4 und höher sowie PowerShell 5.1 sind für windows-Editionen mit vollem Funktionsumfang wie Windows Desktop, Windows Server, Windows Server, Windows Server Core und die meisten anderen Windows-Betriebssysteme verfügbar. Dies ist die ursprüngliche PowerShell-Edition und ist in der Standardinstallation des Betriebssystems enthalten.
- Core, der unter .NET Core ausgeführt wird. PowerShell 6.0 und höher wird parallel zu früheren PowerShell-Releases in Windows-Editionen mit vollem Funktionsumfang, einigen Windows-Editionen mit reduziertem Platzbedarf wie Windows Nano Server und Windows IoT oder auf Nicht-Windows-Plattformen wie Linux und macOS installiert.
Da die Edition von PowerShell der .NET-Runtime entspricht, ist sie der primäre Indikator für die Kompatibilität der .NET-API und des PowerShell-Moduls. Einige .NET-APIs, -Typen oder -Methoden sind in beiden .NET-Runtimes nicht verfügbar. Dies wirkt sich auf PowerShell-Skripts und -Module aus, die davon abhängen.
Die $PSEdition automatische Variable
In PowerShell 5.1 und höher können Sie herausfinden, welche Edition Sie mit der $PSEdition automatischen Variablen ausführen:
$PSEdition
Core
In PowerShell 4 und niedriger ist diese Variable nicht vorhanden. $PSEdition null zu sein, sollte mit dem Wert Desktopgleich behandelt werden.
Edition in $PSVersionTable
Die $PSVersionTable automatische Variable verfügt auch über die PSEdition-Eigenschaft in PowerShell 5.1 und höher:
$PSVersionTable
Name Value
---- -----
PSVersion 7.3.9
PSEdition Core
GitCommitId 7.3.9
OS Microsoft Windows 10.0.22621
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Das PSEdition-Feld hat den gleichen Wert wie die $PSEdition automatische Variable.
Das CompatiblePSEditions Modulmanifestfeld
PowerShell-Module können mithilfe CompatiblePSEditions des Felds des Modulmanifests deklarieren, mit welchen Editionen von PowerShell sie kompatibel sind.
Beispiel: Ein Modulmanifest, das Kompatibilität mit und DesktopCore mit powerShell-Editionen deklariert:
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop', 'Core')
}
Ein Beispiel für ein Modulmanifest mit nur Desktop Kompatibilität:
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop')
}
Das Weglassen des CompatiblePSEditions Felds aus einem Modulmanifest hat die gleiche Auswirkung wie das Festlegen auf Desktop, da Module, die vor der Einführung dieses Felds erstellt wurden, implizit für diese Edition geschrieben wurden.
Für Module, die nicht als Teil von Windows ausgeliefert werden (d. h. Module, die Sie aus dem Katalog schreiben oder installieren), ist dieses Feld nur Informationszwecken; PowerShell ändert das Verhalten nicht basierend auf dem CompatiblePSEditions Feld, macht es aber für das PSModuleInfo -Objekt verfügbar (zurückgegeben von Get-Module) für Ihre eigene Logik:
New-ModuleManifest -Path .\TestModuleWithEdition.psd1 -CompatiblePSEditions Desktop,Core -PowerShellVersion '5.1'
$ModuleInfo = Test-ModuleManifest -Path .\TestModuleWithEdition.psd1
$ModuleInfo.CompatiblePSEditions
Desktop
Core
Hinweis
Das CompatiblePSEditions Modulfeld ist nur mit PowerShell 5.1 und höher kompatibel. Das Einschließen dieses Felds führt dazu, dass ein Modul mit PowerShell 4 und niedriger nicht kompatibel ist. Da das Feld rein informativ ist, kann es in späteren PowerShell-Versionen sicher weggelassen werden.
In PowerShell 6.1 wurde der Formatierer aktualisiert, Get-Module -ListAvailable um die Editionskompatibilität der einzelnen Module anzuzeigen:
Get-Module -ListAvailable
Directory: C:\Users\me\Documents\PowerShell\Modules
ModuleType Version Name PSEdition ExportedCommands
---------- ------- ---- --------- ----------------
Script 1.4.0 Az Core,Desk
Script 1.3.1 Az.Accounts Core,Desk {Disable-AzDataCollection, Disable-AzContextAutosave, E...
Script 1.0.1 Az.Aks Core,Desk {Get-AzAks, New-AzAks, Remove-AzAks, Import-AzAksCreden...
...
Script 4.4.0 Pester Desk {Describe, Context, It, Should...}
Script 1.18.0 PSScriptAnalyzer Desk {Get-ScriptAnalyzerRule, Invoke-ScriptAnalyzer, Invoke-...
Script 1.0.0 WindowsCompatibility Core {Initialize-WinSession, Add-WinFunction, Invoke-WinComm...
Editionskompatibilität für Module, die als Teil von Windows ausgeliefert werden
Bei Modulen, die teil von Windows sind (oder als Teil einer Rolle oder eines Features installiert werden), behandeln PowerShell 6.1 und höher das CompatiblePSEditions Feld unterschiedlich. Solche Module finden Sie im Verzeichnis Windows PowerShell Systemmodule (%windir%\System\WindowsPowerShell\v1.0\Modules).
Für Module, die aus diesem Verzeichnis geladen oder in diesem Verzeichnis gefunden werden, verwendet PowerShell 6.1 und höher das CompatiblePSEditions Feld, um zu bestimmen, ob das Modul mit der aktuellen Sitzung kompatibel ist und sich entsprechend verhält.
Wenn Import-Module verwendet wird, wird ein Modul ohne Core in CompatiblePSEditions nicht importiert, und ein Fehler wird angezeigt:
Import-Module BitsTransfer
Import-Module : Module 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\BitsTransfer\BitsTransfer.psd1'
does not support current PowerShell edition 'Core'. Its supported editions are 'Desktop'. Use 'Import-Module
-SkipEditionCheck' to ignore the compatibility of this module.
At line:1 char:1
+ Import-Module BitsTransfer
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (C:\WINDOWS\system32\u2026r\BitsTransfer.psd1:String)
[Import-Module], InvalidOperationException
+ FullyQualifiedErrorId : Modules_PSEditionNotSupported,Microsoft.PowerShell.Commands.ImportModuleCommand
Bei Get-Module -ListAvailable Verwendung werden Module ohne Core in CompatiblePSEditions nicht angezeigt:
Get-Module -ListAvailable BitsTransfer
# No output
In beiden Fällen kann der -SkipEditionCheck Switch-Parameter verwendet werden, um dieses Verhalten zu überschreiben:
Get-Module -ListAvailable -SkipEditionCheck BitsTransfer
Directory: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
ModuleType Version Name PSEdition ExportedCommands
---------- ------- ---- --------- ----------------
Manifest 2.0.0.0 BitsTransfer Desk {Add-BitsFile, Complete-BitsTransfer, Get-BitsTransfer,...
Warnung
Import-Module -SkipEditionCheck möglicherweise für ein Modul erfolgreich zu sein, aber bei der Verwendung dieses Moduls besteht das Risiko, später auf eine Inkompatibilität zu stoßen; Während das Laden des Moduls zunächst erfolgreich verläuft, kann ein Befehl später eine inkompatible API aufrufen und spontan fehlschlagen.
Erstellen von PowerShell-Modulen für editionsübergreifende Kompatibilität
Beim Schreiben eines PowerShell-Moduls für sowohl als auch DesktopCore für Die Editionen von PowerShell können Sie einiges tun, um die kompatibilität zwischen editionsübergreifenden Versionen sicherzustellen.
Die einzige echte Möglichkeit, die Kompatibilität zu bestätigen und kontinuierlich zu überprüfen, besteht jedoch darin, Tests für Ihr Skript oder Modul zu schreiben und sie für alle Versionen und Editionen von PowerShell auszuführen, mit denen Sie Kompatibilität benötigen. Ein empfohlenes Testframework hierfür ist Pester.
PowerShell-Skript
Als Sprache funktioniert PowerShell zwischen Editionen gleich. Es sind die Cmdlets, Module und .NET-APIs, die Sie verwenden, von der Editionskompatibilität betroffen.
Im Allgemeinen funktionieren Skripts, die in PowerShell 6.1 und höher funktionieren, mit Windows PowerShell 5.1, es gibt jedoch einige Ausnahmen.
PSScriptAnalyzer Version 1.18 und höher verfügt über Regeln wie PSUseCompatibleCommands und PSUseCompatibleTypes , die möglicherweise inkompatible Verwendung von Befehlen und .NET-APIs in PowerShell-Skripts erkennen können.
.NET-Assemblys
Wenn Sie ein binärmodul oder ein Modul schreiben, das aus Quellcode generierte .NET-Assemblys (DLLs) enthält, sollten Sie für die Kompatibilität der .NET- und PowerShell-API mit .NET Standard und PowerShell Standard kompilieren, um die Kompatibilität von .NET und PowerShell-API während der Kompilierzeit zu überprüfen.
Obwohl diese Bibliotheken zur Kompilierzeit eine gewisse Kompatibilität überprüfen können, können sie keine möglichen Verhaltensunterschiede zwischen Editionen abfangen. Dazu müssen Sie weiterhin Tests schreiben.