about_PowerShell_Editions
Kurze Beschreibung
Verschiedene Editionen von PowerShell werden auf verschiedenen zugrunde liegenden Laufzeiten ausgeführt.
Lange Beschreibung
In PowerShell 5.1 gibt es mehrere Editionen von PowerShell, die jeweils auf einer anderen .NET-Laufzeit ausgeführt werden. Ab PowerShell 6.0 gibt es zwei Editionen von PowerShell:
- Desktop, der auf .NET Framework ausgeführt wird. PowerShell 4 und darunter sowie PowerShell 5.1 sind für Windows-Editionen mit vollem Funktionsumfang wie Windows Desktop, 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, das auf .NET Core ausgeführt wird. PowerShell 6.0 und höher werden parallel mit früheren PowerShell-Versionen auf voll funktionsfähigen Windows-Editionen, einigen reduzierten Windows-Editionen wie Windows Nano Server und Windows IoT oder auf Nicht-Windows-Plattformen wie Linux und macOS installiert.
Da die Edition von PowerShell der .NET-Laufzeit entspricht, ist sie der primäre Indikator für .NET-API- und PowerShell-Modulkompatibilität; einige .NET-APIs, Typen oder Methoden sind in .NET-Runtimes nicht verfügbar, und dies wirkt sich auf PowerShell-Skripts und -Module aus, die von ihnen abhängig sind.
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 darunter ist diese Variable nicht vorhanden. $PSEdition der Wert null ist, sollte mit dem Wert Desktopidentisch behandelt werden.
Edition in $PSVersionTable
Die $PSVersionTable automatische Variable verfügt außerdem ü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 weist denselben Wert wie die $PSEdition automatische Variable auf.
Das CompatiblePSEditions Modulmanifestfeld
PowerShell-Module können deklarieren, welche Editionen von PowerShell mit dem CompatiblePSEditions Feld des Modulmanifests kompatibel sind.
Beispiel: Ein Modulmanifest, das die Kompatibilität mit beiden Desktop Editionen Core 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 dieselbe Auswirkung wie das Festlegen Desktopauf , 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 geliefert werden (d. h. Module, die Sie aus dem Katalog schreiben oder installieren), ist dieses Feld nur informational; PowerShell ändert das Verhalten nicht basierend auf dem CompatiblePSEditions Feld, macht es jedoch 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 nicht mit PowerShell 4 und unten 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 als Teil von Windows (oder als Teil einer Rolle oder eines Features installiert sind), behandeln PowerShell 6.1 und höher das CompatiblePSEditions Feld anders. Solche Module finden Sie im Windows PowerShell-Systemmodulverzeichnis (%windir%\System\WindowsPowerShell\v1.0\Modules).
Bei Modulen, die aus diesem Verzeichnis geladen oder gefunden wurden, 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 sie 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 sie 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 außer Kraft zu setzen:
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 erfolgreich für ein Modul, aber die Verwendung dieses Moduls führt das Risiko aus, dass später eine Inkompatibilität auftritt; beim anfänglichen Laden des Moduls kann ein Befehl später eine inkompatible API aufrufen und spontan fehlschlagen.
Erstellen von PowerShell-Modulen für editionübergreifende Kompatibilität
Beim Schreiben eines PowerShell-Moduls für beide Desktop Versionen und Core Editionen von PowerShell gibt es Dinge, die Sie tun können, 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 auf allen 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 gleich zwischen Editionen; es handelt sich um die Cmdlets, Module und .NET-APIs, die Sie verwenden, die von der Editionskompatibilität betroffen sind.
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+ enthält 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 .NET-Assemblys (DLLs) enthält, die aus Quellcode generiert werden, sollten Sie für die Kompilierungszeitkompatibilitätsüberprüfung von .NET- und PowerShell-API-Kompatibilität anhand von .NET Standard und PowerShell Standard kompilieren.
Obwohl diese Bibliotheken zur Kompilierungszeit einige Kompatibilität überprüfen können, können sie keine möglichen Verhaltensunterschiede zwischen Editionen erfassen. Hierfür müssen Sie weiterhin Tests schreiben.
