about_PowerShell_Editions
Kurze Beschreibung
Verschiedene Editionen von PowerShell werden unter 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.2 gibt es zwei Editionen von PowerShell:
- Desktop, der auf .NET Framework ausgeführt wird. PowerShell 4 und niedriger sowie PowerShell 5.1 unter Windows-Editionen mit vollem Funktionsumfang wie Windows Desktop, Windows Server, Windows Server Core und die meisten anderen Windows-Betriebssysteme sind Desktop Edition. Dies ist die ursprüngliche PowerShell-Edition.
- Core, der unter .NET Core ausgeführt wird. PowerShell 6.0 und höher sowie PowerShell 5.1 in einigen Windows-Editionen mit reduziertem Speicherbedarf, z. B. Windows Nano Server und Windows IoT, bei denen .NET Framework nicht verfügbar ist.
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 nicht in beiden .NET-Runtimes 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 sollte mit dem Wert Desktopbehandelt werden.
Edition in $PSVersionTable
Die $PSVersionTable automatische Variable enthält auch Editionsinformationen in PowerShell 5.1 und höher:
$PSVersionTable
Name Value
---- -----
PSVersion 7.1.6
PSEdition Core
GitCommitId 7.1.6
OS Microsoft Windows 10.0.22000
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 PowerShell-Editionen sie kompatibel sind.
Beispielsweise ein Modulmanifest, das kompatibilität mit und DesktopCore editionen von PowerShell deklariert:
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop', 'Core')
}
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 informal; 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 jedes Moduls 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
Für Module, 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 befinden sich im Verzeichnis Windows PowerShell Systemmodule (%windir%\System\WindowsPowerShell\v1.0\Modules).
Für Module, die aus diesem Verzeichnis geladen werden oder sich in diesem Verzeichnis befinden, 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 es wird ein Fehler 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
Wenn Get-Module -ListAvailable verwendet wird, 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 scheint für ein Modul erfolgreich zu sein, aber die Verwendung dieses Moduls birgt das Risiko, dass später eine Inkompatibilität auftritt. Während das Laden des Moduls anfänglich erfolgreich ist, kann ein Befehl später eine inkompatible API aufrufen und spontan fehlschlagen.
Erstellen von PowerShell-Modulen für editionsübergreifende Kompatibilität
Wenn Sie ein PowerShell-Modul für sowohl als auch DesktopCore für die PowerShell-Edition schreiben, können Sie einiges tun, um die kompatibilitätsübergreifende Edition sicherzustellen.
Die einzige wirkliche 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. Von der Editionskompatibilität sind die von Ihnen verwendeten Cmdlets, Module und .NET-APIs 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äres Modul oder ein Modul schreiben, das aus dem Quellcode generierte .NET-Assemblys (DLLs) enthält, sollten Sie für .NET Standard und PowerShell Standard kompilieren, um die Kompatibilität von .NET und PowerShell-API zu überprüfen.
Obwohl diese Bibliotheken zur Kompilierzeit eine gewisse Kompatibilität überprüfen können, können sie mögliche Verhaltensunterschiede zwischen Editionen nicht abfangen. Dazu müssen Sie weiterhin Tests schreiben.