Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Kurzbeschreibung
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-, das 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 Mit der $PSEdition automatischen Variablen ausgeführt wird:
$PSEdition
Core
In PowerShell 4 und darunter ist diese Variable nicht vorhanden.
$PSEdition null sein, sollte mit dem Wert Desktopbehandelt werden.
Ausgabe in $PSVersionTable
Die $PSVersionTable automatische Variable verfügt außerdem über 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 feld PSEdition hat denselben Wert wie die $PSEdition automatische Variable.
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 Desktop- und Core Editionen von PowerShell 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 dieselbe 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 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, stellt es jedoch für das PSModuleInfo -Objekt (zurückgegeben von Get-Module) für Ihre eigene Logik zur Verfügung:
$newModuleManifestSplat = @{
Path = '.\TestModuleWithEdition.psd1'
CompatiblePSEditions = 'Desktop', 'Core'
PowerShellVersion = '5.1'
}
New-ModuleManifest @newModuleManifestSplat
$ModuleInfo = Test-ModuleManifest -Path .\TestModuleWithEdition.psd1
$ModuleInfo.CompatiblePSEditions
Desktop
Core
Anmerkung
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 hat Get-Module -ListAvailable den Formatierer aktualisiert, 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 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 befinden sich im Windows PowerShell-Systemmodulverzeichnis (%windir%\System\WindowsPowerShell\v1.0\Modules).
Für Module, die aus diesem Verzeichnis geladen oder gefunden wurden, verwendet PowerShell 6.1 und höher das feld CompatiblePSEditions, 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 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 für ein Modul erfolgreich erscheinen, 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 Desktop- und Core Editionen von PowerShell gibt es Dinge, die Sie tun können, um die kompatibilitätsübergreifende Kompatibilität 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 anhand .NET Standard- und PowerShell Standard- kompilieren, um die Kompatibilität der .NET- und PowerShell-API kompilieren zu können.
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.
Siehe auch
Zusammenarbeit auf GitHub
Die Quelle für diesen Inhalt finden Sie auf GitHub, wo Sie auch Issues und Pull Requests erstellen und überprüfen können. Weitere Informationen finden Sie in unserem Leitfaden für Mitwirkende.
