Unterschiede zwischen Windows PowerShell 5.1 und PowerShell 7.x
Windows PowerShell 5.1 basiert auf .NET Framework v4.5. Mit der Veröffentlichung von PowerShell 6.0 wurde PowerShell zu einem Open Source-Projekt, das auf .NET Core 2.0 basiert. Der Wechsel von .NET Framework zu .NET Core ermöglichte es PowerShell, zu einer plattformübergreifenden Lösung zu werden. PowerShell läuft unter Windows, macOS und Linux.
Es gibt einige Unterschiede in der PowerShell-Sprache zwischen Windows PowerShell und PowerShell. Die Unterschiede liegen vor allem in der Verfügbarkeit und dem Verhalten von PowerShell-Cmdlets zwischen Windows- und Nicht-Windows-Plattformen sowie in den Änderungen, die sich aus den Unterschieden zwischen dem .NET Framework und dem .NET Core ergeben.
In diesem Artikel werden die wesentlichen Unterschiede und grundlegenden Änderungen zwischen Windows PowerShell und der aktuellen Version von PowerShell zusammengefasst. Diese Zusammenfassung enthält keine neuen Features oder Cmdlets, die hinzugefügt wurden. In diesem Artikel wird auch nicht beschrieben, was sich zwischen den Versionen geändert hat. Ziel dieses Artikels ist es, den aktuellen Stand von PowerShell vorzustellen und zu erläutern, wie es sich von Windows PowerShell unterscheidet. Eine detaillierte Beschreibung der Änderungen zwischen den Versionen und der neuen Features finden Sie in den Artikeln zu den Neuerungen der einzelnen Versionen.
- Neuerungen in PowerShell 7.5
- Neuerungen in PowerShell 7.4
- Neuerungen in PowerShell 7.3
- Neuerungen in PowerShell 7.2
- Neuerungen in PowerShell 7.1
- Neuigkeiten in PowerShell 7.0
- Neuerungen in PowerShell 6.x
.NET Framework und .NET Core
PowerShell unter Linux und macOS verwendet .NET Core. Dabei handelt es sich um eine Teilmenge des vollständigen .NET Frameworks unter Microsoft Windows. Das ist wichtig, da PowerShell den direkten Zugriff auf die zugrunde liegenden Frameworktypen und Methoden bereitstellt. Folglich können Skripts, die unter Windows ausgeführt werden, nicht auf anderen Plattformen als Windows ausgeführt werden, da die Frameworks sich unterscheiden. Weitere Informationen zu Änderungen in .NET Core finden Sie unter Breaking Changes für die Migration von .NET Framework zu .NET Core.
Jedes neue Release von PowerShell basiert auf einer neueren Version von .NET. Es kann Breaking Changes in .NET geben, die sich auf PowerShell auswirken.
- PowerShell 7.5, basierend auf .NET 9.0
- PowerShell 7.4: Basiert auf .NET 8.0
- PowerShell 7.3: Basiert auf .NET 7.0
- PowerShell 7.2 (LTS-current): Basiert auf .NET 6.0 (LTS-current)
- PowerShell 7.1: Basiert auf .NET 5.0
- PowerShell 7.0 (LTS): Basiert auf .NET Core 3.1 (LTS)
- PowerShell 6.2: Basiert auf .NET Core 2.1
- PowerShell 6.1: Basiert auf .NET Core 2.1
- PowerShell 6.0: Basiert auf .NET Core 2.0
Mit der Einführung von .NET Standard 2.0 kann PowerShell viele herkömmliche Windows PowerShell-Module ohne Änderungen laden. Darüber hinaus enthält PowerShell 7 eine Windows PowerShell-Kompatibilitätsfunktion, mit der Sie Windows PowerShell-Module verwenden können, für die weiterhin das vollständige Framework erforderlich ist.
Weitere Informationen finden Sie unter:
Zu beachtende .NET-Methodenänderungen
Während .NET-Methodenänderungen nicht spezifisch für PowerShell sind, können sie sich auf Ihre Skripts auswirken, insbesondere, wenn Sie .NET-Methoden direkt aufrufen. Außerdem gibt es möglicherweise neue Überladungen für Konstruktoren. Das kann sich auf die Erstellung von Objekten mit New-Object
oder der [type]::new()
-Methode auswirken.
.NET hat beispielsweise der [System.String]::Split()
-Methode Überladungen hinzugefügt, die in .NET Framework 4.5 nicht verfügbar sind. Die folgende Liste zeigt die Überladungen für die in Windows PowerShell 5.1 verfügbare Split()
-Methode:
PS> "".Split
OverloadDefinitions
-------------------
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)
Die folgende Liste zeigt die Überladungen für die in PowerShell 7 verfügbare Split()
-Methode:
"".Split
OverloadDefinitions
-------------------
string[] Split(char separator, System.StringSplitOptions options)
string[] Split(char separator, int count, System.StringSplitOptions options)
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string separator, System.StringSplitOptions options)
string[] Split(string separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)
In Windows PowerShell 5.1 können Sie ein Zeichenarray (char[]
) als string
an die Split()
-Methode übergeben. Die Methode teilt die Zielzeichenfolge bei jedem Vorkommen eines Zeichens im Array auf. Der folgende Befehl teilt die Zielzeichenfolge in Windows PowerShell 5.1 auf, jedoch nicht in PowerShell 7:
# PowerShell 7 example
"1111p2222q3333".Split('pq')
1111p2222q3333
Um eine Bindung an die richtige Überladung zu erstellen, müssen Sie die Zeichenfolge in ein Zeichenarray umwandeln:
# PowerShell 7 example
"1111p2222q3333".Split([char[]]'pq')
1111
2222
3333
Nicht mehr im Lieferumfang von PowerShell enthaltene Module
Aus verschiedenen Kompatibilitätsgründen sind die folgenden Module nicht mehr in PowerShell enthalten.
- ISE
- Microsoft.PowerShell.LocalAccounts
- Microsoft.PowerShell.ODataUtils
- Microsoft.PowerShell.Operation.Validation
- PSScheduledJob
- PSWorkflow
- PSWorkflowUtility
PowerShell-Workflow
Der PowerShell-Workflow ist ein Feature in Windows PowerShell, das auf Windows Workflow Foundation (WF) basiert und die Erstellung von stabilen Runbooks für lang andauernde oder parallelisierte Aufgaben ermöglicht.
Aufgrund der fehlenden Unterstützung für Windows Workflow Foundation in .NET Core haben wir den PowerShell-Workflow aus PowerShell entfernt.
Zukünftig soll die native Parallelität in der PowerShell-Sprache ohne Notwendigkeit des PowerShell-Workflows ermöglicht werden.
Wenn für die Fortsetzung eines Skripts nach dem Neustart des Betriebssystems Prüfpunkte erforderlich sind, empfehlen wir die Verwendung des Taskplaners, um beim Betriebssystemstart ein Skript auszuführen. Das Skript muss dabei jedoch seinen Status selbst verwalten (z. B. durch Speichern in eine Datei).
Aus PowerShell entfernte Cmdlets
Für die Module, die in PowerShell enthalten sind, wurden die folgenden Cmdlets aus verschiedenen Kompatibilitätsgründen oder aufgrund der Verwendung nicht unterstützter APIs aus PowerShell entfernt.
CimCmdlets
Export-BinaryMiLog
Microsoft.PowerShell.Core
Add-PSSnapin
Export-Console
Get-PSSnapin
Remove-PSSnapin
Resume-Job
Suspend-Job
Microsoft.PowerShell.Diagnostics
Export-Counter
Import-Counter
Microsoft.PowerShell.Management
Add-Computer
Checkpoint-Computer
Clear-EventLog
Complete-Transaction
Disable-ComputerRestore
Enable-ComputerRestore
Get-ComputerRestorePoint
Get-ControlPanelItem
Get-EventLog
Get-Transaction
Get-WmiObject
Invoke-WmiMethod
Limit-EventLog
New-EventLog
New-WebServiceProxy
Register-WmiEvent
Remove-Computer
Remove-EventLog
Remove-WmiObject
Reset-ComputerMachinePassword
Restore-Computer
Set-WmiInstance
Show-ControlPanelItem
Show-EventLog
Start-Transaction
Test-ComputerSecureChannel
Undo-Transaction
Use-Transaction
Write-EventLog
Microsoft.PowerShell.Utility
Convert-String
ConvertFrom-String
PSDesiredStateConfiguration
Disable-DscDebug
Enable-DscDebug
Get-DscConfiguration
Get-DscConfigurationStatus
Get-DscLocalConfigurationManager
Publish-DscConfiguration
Remove-DscConfigurationDocument
Restore-DscConfiguration
Set-DscLocalConfigurationManager
Start-DscConfiguration
Stop-DscConfiguration
Test-DscConfiguration
Update-DscConfiguration
WMI v1-Cmdlets
Die folgenden WMI v1-Cmdlets wurden aus PowerShell entfernt:
Register-WmiEvent
Set-WmiInstance
Invoke-WmiMethod
Get-WmiObject
Remove-WmiObject
Die Cmdlets des CimCmdlets-Moduls (auch bekannt als WMI v2) erfüllen dieselbe Funktion und bieten neue Funktionen und eine überarbeitete Syntax.
Cmdlet New-WebServiceProxy
entfernt
.NET Core bietet keine Unterstützung für das Windows Communication Framework, das Dienste für die Verwendung des SOAP-Protokolls bereitstellt. Dieses Cmdlet wurde entfernt, weil es SOAP erfordert.
*-Transaction
-Cmdlets entfernt
Die Verwendung dieser Cmdlets war sehr eingeschränkt. Es wurde entschieden, ihre Unterstützung einzustellen.
Complete-Transaction
Get-Transaction
Start-Transaction
Undo-Transaction
Use-Transaction
*-EventLog
-Cmdlets
Aufgrund der Verwendung von nicht unterstützten APIs wurden die*-EventLog
-Cmdlets aus PowerShell entfernt.
Unter Windows stehen Get-WinEvent
und New-WinEvent
zum Abrufen und Erstellen von Ereignissen zur Verfügung.
Cmdlets, die das Windows Presentation Framework (WPF) verwenden
NET Core 3.1 hat die Unterstützung für WPF hinzugefügt, sodass mit der Veröffentlichung von PowerShell 7.0 die folgenden Windows-spezifischen Features wiederhergestellt wurden:
Show-Command
-CmdletOut-GridView
-Cmdlet- ShowWindow-Parameter von
Get-Help
DSC-Änderungen von PowerShell (Desired State Configuration)
Invoke-DscResource
wurde als experimentelles Feature in PowerShell 7.0 wiederhergestellt.
Beginnend mit PowerShell 7.2 wurde das PSDesiredStateConfiguration-Modul aus PowerShell entfernt und im PowerShell-Katalog veröffentlicht. Weitere Informationen finden Sie im PowerShell-Teamblog in der Ankündigung.
Ausführbare PowerShell-Änderungen
powershell.exe
in pwsh.exe
umbenannt
Der binäre Name für PowerShell wurde von powershell(.exe)
in pwsh(.exe)
geändert. So können Benutzer PowerShell deterministisch auf Computern ausführen und parallele Installationen von Windows PowerShell und PowerShell unterstützen.
Weitere Änderungen in pwsh(.exe)
im Vergleich zu powershell.exe
:
- Der erste positionelle Parameter wurde von
-Command
in-File
geändert.#!
, auch Shebang genannt, wird damit nicht mehr in PowerShell-Skripts benötigt, die über Nicht-PowerShell-Shells auf Nicht-Windows-Plattformen ausgeführt werden. Damit können Sie auch Befehle wiepwsh foo.ps1
oderpwsh fooScript
ausführen, ohne-File
anzugeben. Beim Versuch, einen Befehl wiepwsh.exe -Command Get-Command
auszuführen, muss für diese Änderung jedoch-c
oder-Command
explizit angegeben werden. pwsh
akzeptiert den Schalter-i
(oder-Interactive
), um eine interaktive Shell anzuzeigen. Daher kann PowerShell als Standard-Shell auf Unix-Plattformen verwendet werden.- Die Parameter
-ImportSystemModules
und-PSConsoleFile
wurden auspwsh.exe
entfernt. pwsh -version
wurde geändert, und Hilfe fürpwsh.exe
bei der Ausrichtung an anderen nativen Tools wurde integriert.- Ungültige Argument-Fehlermeldungen für
-File
und-Command
und mit den Unix-Standards konsistente Exitcodes - Parameter
-WindowStyle
unter Windows hinzugefügt. Paketbasierte Installationsupdates auf Nicht-Windows-Plattformen werden direkt installiert.
Der abgekürzte Name ist ebenfalls mit der Benennung von Shells in anderen Plattformen als Windows konsistent.
Unterstützung der Ausführung eines PowerShell-Skripts mit dem bool-Parameter
Zuvor wurde bei der Verwendung von pwsh.exe
, um ein PowerShell-Skript mithilfe von -File
auszuführen, keine Möglichkeit bereitgestellt, $true
/$false
als Parameterwert zu übergeben. Die Unterstützung für $true
/$false
als analysierte Werte für Parameter wurde hinzugefügt. Switchwerte werden ebenfalls unterstützt.
Verbesserte Abwärtskompatibilität mit Windows PowerShell
Für Windows wurde Import-Module
der neue Schalterparameter UseWindowsPowerShell hinzugefügt. Dieser Schalter erstellt in PowerShell 7 ein Proxymodul, das einen lokalen Windows PowerShell-Prozess verwendet, um alle in diesem Modul enthaltenen Cmdlets implizit auszuführen. Weitere Informationen finden Sie unter Import-Module.
Weitere Informationen dazu, welche Microsoft-Module mit PowerShell 7.0 funktionieren, finden Sie in der Tabelle zur Modulkompatibilität.
Microsoft Update-Unterstützung für Windows
Zusätzlicher PowerShell 7.2-Support für Microsoft Update. Wenn Sie dieses Feature aktivieren, erhalten Sie die aktuellen PowerShell 7-Updates in Ihrem üblichen Windows Update-Verwaltungsflow. Dies gilt sowohl für Windows Update for Business, WSUS und SCCM als auch für das interaktive Windows Update-Dialogfeld in den Einstellungen.
Das PowerShell 7.2 MSI-Paket enthält die folgenden Befehlszeilenoptionen:
USE_MU
: Diese Eigenschaft verfügt über zwei mögliche Werte:1
(Standardeinstellung): aktiviert Updates über Microsoft Update oder WSUS0
– automatische Updates über Microsoft Update oder WSUS werden nicht aktiviert
ENABLE_MU
1
(Standardeinstellung): aktiviert die Verwendung von Microsoft Update, automatischen Updates oder Windows Update0
: keine Aktivierung der Verwendung von Microsoft Update, automatischen Updates oder Windows Update
Moduländerungen
Unterstützung von PowerShell als Unix-Standardshell
Unter Unix ist es Konvention, dass Shells -i
für eine inaktive Shell akzeptieren und viele Tools dieses Verhalten erwarten (z.B. script
und wenn PowerShell als Standardshell festgelegt wird) und die Shell mit dem Parameter -i
aufrufen. Dies ist ein Breaking Change, da -i
zuvor einfach verwendet werden konnte, um mit -inputformat
übereinzustimmen. Nun muss hierfür -in
verwendet werden.
Benutzerdefinierte Snap-Ins
PowerShell-Snap-Ins sind die Vorgänger von PowerShell-Modulen und sind in der PowerShell-Community nicht weit verbreitet.
Aufgrund der Komplexität der unterstützenden Snap-Ins und der zu geringen Verwendung in der Community werden benutzerdefinierte Snap-Ins in PowerShell nicht mehr unterstützt.
Experimentelle Featureflags
Aktivierter Support für PowerShell 6.2 für Experimentelle Features. Auf diese Weise können PowerShell-Entwickler neue Funktionen bereitstellen und Feedback erhalten, bevor der Entwurf abgeschlossen ist. Auf diese Weise vermeiden wir, dass wir bei der Weiterentwicklung des Entwurfs Breaking Changes vornehmen.
Verwenden Sie Get-ExperimentalFeature
, um eine Liste der verfügbaren experimentellen Features abzurufen. Sie können diese Features mit Enable-ExperimentalFeature
und Disable-ExperimentalFeature
aktivieren oder deaktivieren.
Assembly wird vor dem Versuch, aus dem GAC geladen zu werden, aus dem Modulbasispfad geladen
Wenn ein binäres Modul die Modulassembly im GAC enthält, wurde die Assembly bisher aus dem GAC geladen, bevor versucht wurde, sie aus dem Modulbasispfad zu laden.
Überspringen der Überprüfung auf NULL-Elemente für Sammlungen mit einem Werttyp
Überspringen Sie beim Parameter Mandatory
und bei den Attributen ValidateNotNull
und ValidateNotNullOrEmpty
die Überprüfung auf NULL-Elemente, wenn der Elementtyp der Sammlung ein Werttyp ist.
Beibehaltung von $?
für ParenExpression, SubExpression und ArrayExpression
Dieser PR ändert die Art und Weise, wie wir Unterpipelines (...)
, Teilausdrücke $(...)
und Arrayausdrücke @()
kompilieren, sodass $?
nicht automatisch true ist. Stattdessen hängt der Wert von $?
vom Ergebnis der ausgeführten Pipeline oder Anweisungen ab.
Fix $?
darf nicht $false
sein, wenn der native Befehl in stderr
schreibt
$?
ist nicht auf $false
festgelegt, wenn der native Befehl in stderr
schreibt. Es kommt häufig vor, dass native Befehle ohne die Absicht in stderr
schreiben, einen Fehler zu melden. $?
wird nur auf $false
festgelegt, wenn der native Befehl einen Exitcode ungleich Null aufweist.
Veranlassen, dass $ErrorActionPreference
sich nicht auf die stderr
-Ausgabe nativer Befehle auswirkt
Es kommt häufig vor, dass native Befehle ohne die Absicht in stderr
schreiben, einen Fehler zu melden. Mit dieser Änderung wird die stderr
-Ausgabe weiterhin in ErrorRecord-Objekten aufgezeichnet, die Runtime wendet $ErrorActionPreference
jedoch nicht mehr an, wenn ErrorRecord aus einem nativen Befehl stammt.
Ändern von $OutputEncoding
, um die UTF-8 NoBOM
-Codierung statt ASCII zu verwenden
Die vorherige Codierung (ASCII, 7 Bit) würde in manchen Fällen zu falschen Änderungen der Ausgabe führen. Indem UTF-8 NoBOM
als Standard festgelegt wird, wird die Unicode-Ausgabe mit einer Codierung beibehalten, die von den meisten Tools und Betriebssystemen unterstützt wird.
Vereinheitlichung von Cmdlets mit Parameter -Encoding
mit dem Typ System.Text.Encoding
Der -Encoding
-Wert Byte
wurde aus den Cmdlets des Dateisystemanbieters entfernt. Der neue Parameter -AsByteStream
wird nun verwendet, um anzugeben, dass ein Bytestream als Eingabe erforderlich ist oder dass die Ausgabe ein Bytestream ist.
Änderung der New-ModuleManifest
-Codierung in UTF8NoBOM
auf anderen Plattformen als Windows
Zuvor hat New-ModuleManifest
psd1
-Manifeste in UTF-16 mit Bytereihenfolge-Marken erstellt, wodurch ein Problem für Linux-Tools entstand. Durch diese Änderung wird die Codierung auf anderen Plattformen als Windows von New-ModuleManifest
in UTF (ohne Bytereihenfolge-Marken) geändert.
Entfernen von AllScope
aus den meisten Standardaliasen
AllScope
wurde aus den meisten Standardaliasen entfernt, um die Erstellung von Bereichen zu beschleunigen. In einigen häufig verwendeten Aliasen, in denen die Suche schneller ist, wurde AllScope
beibehalten.
-Verbose
und -Debug
überschreibt nicht länger $ErrorActionPreference
Zuvor wurde das Verhalten von $ErrorActionPreference
überschrieben, wenn -Verbose
oder -Debug
angegeben wurden. Durch diese Änderung wirken -Verbose
und -Debug
sich nicht mehr auf das Verhalten von $ErrorActionPreference
aus.
Außerdem legt der -Debug
-Parameter $DebugPreference
auf Continue anstatt auf Inquire fest.
Veranlassen, dass $PSCulture
Veränderungen der Kultur innerhalb der Sitzung konsistent widerspiegelt
In Windows PowerShell wird der aktuelle Kulturwert zwischengespeichert, was dazu führen kann, dass der Wert nicht mehr mit der nach dem Sitzungsstart geänderten Kultur synchronisiert ist. Dieses Zwischenspeicherverhalten wurde in PowerShell Core behoben.
Explizit angegebenem benannten Parameter erlauben, denselben über das Splatting von Hashtabellen zu ersetzen
Mit dieser Änderung werden die benannten Parameter aus dem Splatting an das Ende der Parameterliste verschoben, sodass sie erst nach dem Binden aller explizit angegebenen benannten Parameter gebunden werden. Die Parameterbindung für einfache Funktionen löst keinen Fehler aus, wenn ein angegebener benannter Parameter nicht gefunden werden kann. Unbekannte benannte Parameter sind an den $args
-Parameter der einfachen Funktion gebunden. Durch Verschieben des Splattings an das Ende der Argumentliste wird die Reihenfolge geändert, in der die Parameter in $args
angezeigt werden.
Beispiele:
function SimpleTest {
param(
$Name,
$Path
)
"Name: $Name; Path: $Path; Args: $args"
}
Im vorherigen Verhalten ist MyPath das dritte Argument in der Argumentliste und daher nicht an -Path
gebunden. Aus diesem Grund wird MyPath zusammen mit Blah = "World"
in $args platziert.
PS> $hash = @{ Name = "Hello"; Blah = "World" }
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: ; Args: -Blah: World MyPath
Mit dieser Änderung werden die Argumente aus @hash
an das Ende der Argumentliste verschoben. MyPath wird zum ersten Argument in der Liste, sodass es an -Path
gebunden ist.
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World
Sprachenänderungen
NULL-Sammeloperator ??
Der NULL-Sammeloperator ??
gibt den Wert seines linken Operanden zurück, wenn er nicht NULL ist.
Andernfalls wertet er den rechten Operanden aus und gibt sein Ergebnis zurück. Der Operator ??
wertet seinen rechten Operanden nicht aus, wenn der linke Operand mit ungleich NULL auswertet wird.
$x = $null
$x ?? 100
100
Im folgenden Beispiel wird der rechte Operand nicht ausgewertet.
[string] $todaysDate = '1/10/2020'
$todaysDate ?? (Get-Date).ToShortDateString()
1/10/2020
Der NULL-Sammelzuordnungsoperator??=
Der NULL-Sammelzuordnungsoperator??=
weist den Wert seines rechten Operanden dem linken Operanden nur zu, wenn der linke Operand mit NULL ausgewertet wird. Der Operator ??=
wertet seinen rechten Operanden nicht aus, wenn der linke Operand mit ungleich NULL auswertet wird.
$x = $null
$x ??= 100
$x
100
Im folgenden Beispiel wird der rechte Operand nicht ausgewertet.
[string] $todaysDate = '1/10/2020'
$todaysDate ??= (Get-Date).ToShortDateString()
1/10/2020
Bedingter NULL-Operator
Hinweis
Dieses Feature wurde von „Experimentell“ in „Mainstream“ in PowerShell 7.1 verschoben.
Ein bedingter NULL-Operator erlaubt den Memberzugriff ?.
oder Elementzugriff ?[]
auf seinen Operanden nur dann, wenn dieser Operand mit ungleich NULL ausgewertet wird. Andernfalls gibt er NULL zurück.
Da PowerShell erlaubt, dass ?
Teil des Variablennamens ist, ist für die Verwendung dieser Operatoren die formale Angabe des Variablennamens erforderlich. Daher ist es nötig, {}
um die Variablennamen herum zu platzieren, wie z. B. ${a}
oder wenn ?
Teil des Variablennamens ${a?}
ist.
Im folgenden Beispiel wird der Wert von PropName zurückgegeben.
$a = @{ PropName = 100 }
${a}?.PropName
100
Das folgende Beispiel gibt NULL zurück, ohne dass versucht wird, auf den Membernamen PropName zuzugreifen.
$a = $null
${a}?.PropName
Auf ähnliche Weise wird der Wert des Elements zurückgegeben.
$a = 1..10
${a}?[0]
1
Wenn der Operand NULL ist, wird nicht auf das Element zugegriffen und NULL zurückgegeben.
$a = $null
${a}?[0]
Hinweis
Die Syntax des Variablennamens ${<name>}
sollte nicht mit dem $()
-Subexpression-Operator verwechselt werden. Weitere Informationen finden Sie im Abschnitt „Variablenname“ von about_Variables.
&
-Operator für Auftragssteuerung hinzugefügt
Wenn Sie ein &
am Ende einer Pipeline einfügen, wird die Pipeline als PowerShell-Auftrag ausgeführt. In diesem Fall wird ein Auftragsobjekt zurückgegeben. Wird die Pipeline als Auftrag ausgeführt, kann sie mithilfe aller Standard-*-Job
-Cmdlets verwaltet werden. Die in der Pipeline verwendeten Variablen (außer der prozessspezifischen) werden automatisch in den Auftrag kopiert, sodass Copy-Item $foo $bar &
funktioniert. Der Auftrag wird auch im aktuellen Verzeichnis statt im Basisverzeichnis des Benutzers ausgeführt.
Neue Methoden/Eigenschaften für PSCustomObject
Wir haben neue Methoden und Eigenschaften zu PSCustomObject
hinzugefügt. PSCustomObject
enthält nun eine Count
/Length
-Eigenschaften wie andere Objekte.
$PSCustomObject = [pscustomobject]@{foo = 1}
$PSCustomObject.Length
1
$PSCustomObject.Count
1
Diese Vorgehensweise umfasst auch ForEach
- und Where
-Methoden, mit denen Sie nach PSCustomObject
-Elementen ausführen und filtern können:
$PSCustomObject.ForEach({$_.foo + 1})
2
$PSCustomObject.Where({$_.foo -gt 0})
foo
---
1
Konvertierungen von PSMethod in einen Delegaten
Sie können eine PSMethod
in einen Delegaten konvertieren. Dadurch kann nun beispielsweise PSMethod
[M]::DoubleStrLen
als Delegatwert an [M]::AggregateString
übergeben werden:
class M {
static [int] DoubleStrLen([string] $value) { return 2 * $value.Length }
static [long] AggregateString([string[]] $values, [func[string, int]] $selector) {
[long] $res = 0
foreach($s in $values){
$res += $selector.Invoke($s)
}
return $res
}
}
[M]::AggregateString((gci).Name, [M]::DoubleStrLen)
Verhalten beim Zeichenfolgenvergleich in PowerShell 7.1 geändert
PowerShell 7.1 basiert auf .NET 5.0, wodurch folgender Breaking Change eingeführt wurde:
Ab .NET 5.0 ignorieren kulturunabhängige Zeichenfolgenvergleiche nicht druckbare Steuerzeichen.
Beispielsweise werden die folgenden beiden Zeichenfolgen als identisch betrachtet:
# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"
True
Neue Cmdlets
Neues Get-Uptime-Cmdlet
Das Get-Uptime-Cmdlet gibt die seit dem letzten Start des Betriebssystems verstrichene Zeit zurück. Dieses Cmdlet wurde in PowerShell 6.0 eingeführt.
Neues Remove-Alias-Cmdlet
Das Remove-Alias-Cmdlet entfernt einen Alias aus der aktuellen PowerShell-Sitzung. Dieses Cmdlet wurde in PowerShell 6.0 eingeführt.
Neues „Remove-Service“-Cmdlet
Das Remove-Service-Cmdlet entfernt einen Windows-Dienst in der Registrierung und in der Dienstdatenbank. Das Remove-Service
-Cmdlet wurde in PowerShell 6.0 eingeführt.
Neue Markdown-Cmdlets
Markdown ist eine Standardsprache zum Erstellen von lesbaren Nur-Text-Dokumenten mit grundlegender Formatierung, die in HTML gerendert werden kann.
Die folgenden Cmdlets wurden in PowerShell 6.1 hinzugefügt:
- ConvertFrom-Markdown – Konvertieren des Inhalts einer Zeichenfolge oder einer Datei in ein MarkdownInfo-Objekt.
- Get-MarkdownOption – Gibt die aktuellen Farben und Stile zurück, die zum Rendern von Markdown-Inhalten in der Konsole verwendet werden.
- Set-MarkdownOption – Gibt die aktuellen Farben und Stile zurück, die zum Rendern von Markdown-Inhalten in der Konsole verwendet werden.
- Show-Markdown – Zeigt Markdown-Inhalte in der Konsole oder als HTML an
Neues Test-Json-Cmdlet
Das Test-Json-Cmdlet testet, ob eine Zeichenfolge ein gültiges JavaScript-Objektnotation -Dokument (JSON) ist und optional überprüfen kann, ob das JSON-Dokument für ein angegebenes Schema verwendet wird.
Das Cmdlet wurde in PowerShell 6.1 eingeführt
Neue Cmdlets zur Unterstützung experimenteller Features
Die folgenden Cmdlets wurden in PowerShell 6.2 hinzugefügt, um experimentelle Features zu unterstützen.
Neues Join-String-Cmdlet
Das Join-String-Cmdlet kombiniert Objekte aus der Pipeline in eine einzelne Zeichenfolge. Dieses Cmdlet wurde in PowerShell 6.2 hinzugefügt.
Neue Ansicht ConciseView und neues Cmdlet Get-Error
PowerShell 7.0 verbessert die Anzeige von Fehlermeldungen, um die Lesbarkeit von Interaktions- und Skriptfehlern mithilfe einer neuen Standardansicht namens ConciseView zu optimieren. Die Ansichten sind vom Benutzer über die Einstellungsvariable $ErrorView
auswählbar.
Wenn bei ConciseView ein Fehler nicht von einem Skript- oder Parserfehler herrührt, handelt es sich um eine einzeilige Fehlermeldung:
Get-Childitem -Path c:\NotReal
Get-ChildItem: Cannot find path 'C:\NotReal' because it does not exist
Wenn der Fehler während der Skriptausführung auftritt oder ein Analysefehler ist, gibt PowerShell eine mehrzeilige Fehlermeldung zurück. Diese enthält den Fehler, einen Zeiger und eine Fehlermeldung, die angibt, wo der Fehler in dieser Zeile vorliegt. Wenn das Terminal keine farbigen Escapesequenzen nach ANSI (VT100) unterstützt, werden keine Farben angezeigt.
Die Standardansicht in PowerShell 7 ist ConciseView. Die vorherige Standardansicht war NormalView, die Sie durch Festlegen der Einstellungsvariablen $ErrorView
auswählen können.
$ErrorView = 'NormalView' # Sets the error view to NormalView
$ErrorView = 'ConciseView' # Sets the error view to ConciseView
Hinweis
Die neue Eigenschaft ErrorAccentColor wird zu $Host.PrivateData
hinzugefügt, um die Änderung der Akzentfarbe der Fehlermeldung zu unterstützen.
Das neue Get-Error
-Cmdlet bietet auf Wunsch eine vollständige Detailansicht des vollqualifizierten Fehlers. Standardmäßig zeigt das Cmdlet die vollständigen Details, einschließlich innerer Ausnahmen, des zuletzt aufgetretenen Fehlers an.
Das Cmdlet Get-Error
unterstützt die Eingabe aus der Pipeline unter Verwendung der integrierten Variablen $Error
.
Get-Error
zeigt alle weitergeleiteten Fehler an.
$Error | Get-Error
Das Cmdlet Get-Error
unterstützt den Parameter Newest, mit dem Sie angeben können, wie viele Fehler aus der aktuellen Sitzung angezeigt werden sollen.
Get-Error -Newest 3 # Displays the lst three errors that occurred in the session
Weitere Informationen finden Sie unter Get-Error.
Änderungen an Cmdlets
Parallele Ausführung zu ForEach-Object hinzugefügt
DasForEach-Object
-Cmdlet, das Elemente in einer Sammlung iteriert und in PowerShell 7.0 beginnt, zeichnet sich nun dank des neuen Parameters Parallel durch integrierte Parallelität aus.
Standardmäßig verwenden parallele Skriptblöcke das aktuelle Arbeitsverzeichnis des Aufrufers, der die parallelen Aufgaben gestartet hat.
In diesem Beispiel werden 50.000 Protokolleinträge aus 5 Systemprotokollen auf einem lokalen Windows-Computer abgerufen:
$logNames = 'Security','Application','System','Windows PowerShell','Microsoft-Windows-Store/Operational'
$logEntries = $logNames | ForEach-Object -Parallel {
Get-WinEvent -LogName $_ -MaxEvents 10000
} -ThrottleLimit 5
$logEntries.Count
50000
Der Parameter Parallel gibt den Skriptblock an, der für jeden Eingabeprotokollnamen parallel ausgeführt wird.
Der neue Parameter ThrottleLimit begrenzt die Anzahl der zu einer bestimmten Zeit parallel ausgeführten Skriptblöcke. Der Standardwert ist 5.
Verwenden Sie die Variable $_
, um das aktuelle Eingabeobjekt im Skriptblock darzustellen. Verwenden Sie den Bereich $using:
, um Variablenverweise an den ausgeführten Skriptblock zu übergeben.
Weitere Informationen finden Sie unter ForEach-Object.
Überprüfen von system32
nach kompatiblen integrierten Modulen unter Windows
Im Update 1809 für Windows 10 und im Update für Windows Server 2019 wurden eine Reihe von integrierten PowerShell-Modulen aktualisiert, um sie als mit PowerShell kompatibel zu kennzeichnen.
Beim Starten von PowerShell wird automatisch $windir\System32
als Teil der PSModulePath
-Umgebungsvariable mit einbezogen. Allerdings werden Module nur dann Get-Module
und Import-Module
verfügbar gemacht, wenn CompatiblePSEdition
als kompatibel mit Core
gekennzeichnet ist.
Mit dem Switch-Parameter -SkipEditionCheck
können Sie dieses Verhalten so überschreiben, dass alle Module angezeigt werden.
Außerdem wurde der Tabellenausgabe eine PSEdition
-Eigenschaft hinzugefügt.
-lp
-Alias für alle -LiteralPath
-Parameter
Wir haben einen Standardparameteralias -lp
für alle integrierten PowerShell-Cmdlets erstellt, die einen -LiteralPath
-Parameter aufweisen.
Korrigieren von Get-Item -LiteralPath a*b
, wenn a*b
nicht vorhanden ist, um Fehler zurückzugeben
Zuvor wurde ein -LiteralPath
-Cmdlet im Hintergrund beendet, wenn ein Platzhalter es wie -Path
behandelt und dieser keine Dateien findet. Korrekterweise sollte -LiteralPath
ein Literal sein, sodass ein Fehler angezeigt wird, wenn die Datei nicht vorhanden ist. Die Änderung besteht darin, dass Platzhalter, die mit -Literal
verwendet werden, als Literal behandelt werden.
Festlegung des Arbeitsverzeichnisses auf das aktuelle Verzeichnis in Start-Job
Das Start-Job
-Cmdlet verwendet jetzt das aktuelle Verzeichnis als Arbeitsverzeichnis für den neuen Auftrag.
Entfernung von -Protocol
aus *-Computer
-Cmdlets
Aufgrund von Problemen mit dem RPC-Remoting in CoreFX (insbesondere auf anderen Plattformen als Windows) und zur Gewährleistung einer konsistenten Remotingumgebung in PowerShell wurde der Parameter -Protocol
aus den \*-Computer
-Cmdlets entfernt. DCOM wird für das Remoting nicht mehr unterstützt. Die folgenden Cmdlets unterstützen nur das WSMAN-Remoting:
Rename-Computer
Restart-Computer
Stop-Computer
Entfernung von -ComputerName
aus *-Service
-Cmdlets
Der Parameter -ComputerName
wurde aus *-Service
-Cmdlets entfernt, um die konsistente Verwendung von PSRP zu fördern.
Get-Content -Delimiter
sollte kein Trennzeichen in den zurückgegebenen Zeilen enthalten
Zuvor war die Ausgabe bei der Verwendung von Get-Content -Delimiter
inkonsistent und unpraktisch, da weitere Verarbeitung der Daten erforderlich ist, um das Trennzeichen zu entfernen. Durch diese Änderung wird das Trennzeichen aus den zurückgegebenen Zeilen entfernt.
Änderungen an Format-Hex
Der Parameter -Raw
ist nun kein Vorgang mehr (d.h. er führt keine Aktion aus). In Zukunft werden alle Ausgaben mit einer echten Darstellung von Zahlen angezeigt, die alle Bytes des jeweiligen Typs enthält. Dies war die Aufgabe des -Raw
-Parameters vor dieser Änderung.
Behebung eines Tippfehlers im Eigenschaftenname von Get-ComputerInfo
BiosSerialNumber
wurde fälschlicherweise als BiosSeralNumber
geschrieben und wurde in die richtige Schreibweise geändert.
Hinzufügen der Cmdlets Get-StringHash
und Get-FileHash
Diese Änderung besteht darin, dass einige Hashalgorithmen von CoreFX nicht unterstützt werden und deshalb nicht mehr verfügbar sind.
MACTripleDES
RIPEMD160
Hinzufügung der Überprüfung von Get-*
-Cmdlets, wenn mein Übergeben von „$null“ alle Objekte statt eines Fehlers zurückgegeben werden
Das Übergeben von $null
an eines der folgenden Cmdlets löst nun einen Fehler aus:
Get-Credential -UserName
Get-Event -SourceIdentifier
Get-EventSubscriber -SourceIdentifier
Get-Help -Name
Get-PSBreakpoint -Script
Get-PSProvider -PSProvider
Get-PSSessionConfiguration -Name
Get-Runspace -Name
Get-RunspaceDebug -RunspaceName
Get-Service -Name
Get-TraceSource -Name
Get-Variable -Name
Unterstützung für das erweiterte W3C-Protokolldateiformat in Import-Csv
hinzugefügt
Zuvor konnte das Cmdlet Import-Csv
nicht verwendet werden, um die Protokolldateien direkt im erweiterten W3C-Protokollformat zu importieren. Hierfür waren zusätzliche Aktionen erforderlich. Durch diese Änderung wird das erweiterte W3C-Protokollformat unterstützt.
Import-Csv
wendet PSTypeNames
beim Import an, wenn die Typinformationen in der CSV-Datei vorhanden sind
Zuvor behielten exportierte Objekte, die Export-CSV
mit TypeInformation
verwenden und mit ConvertFrom-Csv
importiert wurden, die Typinformationen nicht bei. Durch diese Änderung werden die Typinformationen zum Member PSTypeNames
hinzugefügt, wenn Sie in der CSV-Datei vorhanden sind.
-NoTypeInformation
ist der Standardwert bei Export-Csv
Zuvor gab das Cmdlet Export-CSV
einen Kommentar als erste Zeile aus, der den Typnamen des Objekts enthielt. Die Änderung schließt die Typinformationen standardmäßig aus, da sie von den meisten CSV-Tools nicht verstanden werden. Diese Änderung wurde aufgrund des Feedbacks von Kunden vorgenommen.
Verwenden Sie -IncludeTypeInformation
, um das vorherigen Verhalten beizubehalten.
*
kann jetzt im Registrierungspfad für Remove-Item
verwendet werden
Zuvor wurde ein -LiteralPath
-Cmdlet im Hintergrund beendet, wenn ein Platzhalter es wie -Path
behandelt und dieser keine Dateien findet. Korrekterweise sollte -LiteralPath
ein Literal sein, sodass ein Fehler angezeigt wird, wenn die Datei nicht vorhanden ist. Die Änderung besteht darin, dass Platzhalter, die mit -Literal
verwendet werden, als Literal behandelt werden.
Group-Object sortiert jetzt die Gruppen
Im Rahmen der Leistungsverbesserung gibt Group-Object
jetzt eine sortierte Auflistung der Gruppen zurück.
Obwohl Sie sich auf die Reihenfolge nicht verlassen sollten, könnte diese Änderung zu einer Teilung führen, wenn Sie die erste Gruppe anzeigen möchten. Wir haben entschieden, dass diese Leistungsverbesserung die Änderung wert wäre, weil sich die Abhängigkeit vom früheren Verhalten nur geringfügig auswirkt.
Standardabweichung in Measure-Object
Die Ausgabe von Measure-Object
enthält jetzt eine StandardDeviation
-Eigenschaft.
Get-Process | Measure-Object -Property CPU -AllStats
Count : 308
Average : 31.3720576298701
Sum : 9662.59375
Maximum : 4416.046875
Minimum :
StandardDeviation : 264.389544720926
Property : CPU
Get-PfxCertificate -Password
Get-PfxCertificate
verfügt jetzt über den Password
-Parameter, der ein SecureString
übernimmt. Dadurch kann er ohne Benutzereingriff verwendet werden:
$certFile = '\\server\share\pwd-protected.pfx'
$certPass = Read-Host -AsSecureString -Prompt 'Enter the password for certificate: '
$certThumbPrint = (Get-PfxCertificate -FilePath $certFile -Password $certPass ).ThumbPrint
Entfernen der more
-Funktion
Bisher enthielt PowerShell unter Windows eine Funktion mit dem Namen more
, die more.com
mit einschloss. Diese Funktion wurde nun entfernt.
Zudem wurde die help
-Funktion so geändert, dass unter Windows more.com
verwendet wird bzw. auf anderen Plattformen der unter $env:PAGER
angegebene Standardpager des Systems.
Zurückleiten der Benutzer zum aktuellen Arbeitsverzeichnis im Laufwerk mit cd DriveName:
Bisher wurden Benutzer zum Standardspeicherort für das Laufwerk geleitet, wenn sie mit Set-Location
oder cd
zu einem PowerShell-Laufwerk (PSDrive) zurückkehren wollten. Benutzer werden jetzt zum letzten bekannten aktuellen Arbeitsverzeichnis für die jeweilige Sitzung geleitet.
Zurück zum vorherigen Verzeichnis mit cd -
C:\Windows\System32> cd C:\
C:\> cd -
C:\Windows\System32>
Oder unter Linux:
PS /etc> cd /usr/bin
PS /usr/bin> cd -
PS /etc>
cd
und cd --
wechseln auch zu $HOME
.
Update-Help
als Nicht-Administrator
Aufgrund der großen Nachfrage muss nun Update-Help
nicht mehr als Administrator ausgeführt werden. Über Update-Help
wird die Hilfe jetzt standardmäßig in einen benutzerdefinierten Ordner gespeichert.
Where-Object -Not
Durch das Hinzufügen des -Not
-Parameters zu Where-Object
können Sie ein Objekt in der Pipeline nach dem Nichtvorhandensein einer Eigenschaft oder eines leeren oder NULL-Eigenschaftswerts filtern.
Dieser Befehl gibt z.B. alle Dienste zurück, die über keine definierten abhängigen Dienste verfügen:
Get-Service | Where-Object -Not DependentServices
Änderungen an Web-Cmdlets
Die zugrunde liegende .NET-API der Web-Cmdlets wurde in System.Net.Http.HttpClient
geändert. Diese Änderung bietet viele Vorteile. Diese Änderung führte jedoch zusammen mit der mangelnden Interoperabilität mit Internet Explorer dazu, dass einige Breaking Changes in Invoke-WebRequest
und Invoke-RestMethod
auftraten.
Invoke-WebRequest
unterstützt nun ausschließlich die grundlegende HTML-Analyse.Invoke-WebRequest
gibt immer einBasicHtmlWebResponseObject
-Objekt zurück. Die EigenschaftenParsedHtml
undForms
wurden entfernt.- Die
BasicHtmlWebResponseObject.Headers
-Werte entsprechen nunString[]
stattString
. BasicHtmlWebResponseObject.BaseResponse
ist nun einSystem.Net.Http.HttpResponseMessage
-Objekt.- Die
Response
-Eigenschaft von Web-Cmdlet-Ausnahmen ist nun einSystem.Net.Http.HttpResponseMessage
-Objekt. - Die strenge RFC-Headeranalyse wird nun standardmäßig für den
-Headers
- und-UserAgent
-Parameter durchgeführt. Dies kann mit-SkipHeaderValidation
umgangen werden. - Die URI-Schemas
file://
undftp://
werden nicht mehr unterstützt. - Die
System.Net.ServicePointManager
-Einstellungen werden nicht mehr berücksichtigt. - Derzeit ist keine zertifikatbasierte Authentifizierung unter macOS verfügbar.
- Das Verwenden eines
-Credential
- statt einemhttp://
-URI führt zu einem Fehler. Verwenden Sie einenhttps://
-URI, oder geben Sie den-AllowUnencryptedAuthentication
-Parameter an, um den Fehler zu unterdrücken. -MaximumRedirection
erzeugt nun einen Fehler mit Abbruch, wenn Umleitungsversuche die angegebene Grenze überschreiten, anstatt die Ergebnisse der letzten Umleitung zurückzugeben.- In PowerShell 6.2 wurde eine Änderung an der standardmäßigen UTF-8-Codierung für JSON-Antworten vorgenommen. Wenn für eine JSON-Antwort kein Zeichensatz angegeben wird, muss die Standardcodierung gemäß RFC 8259 UTF-8 lauten.
- Standardcodierung für
application-json
-Antworten auf UTF-8 festgelegt - Hinzufügen des
-SkipHeaderValidation
-Parameters zum Zulassen vonContent-Type
-Headern, die nicht mit den Standards kompatibel sind - Hinzufügen des
-Form
-Parameters zur Unterstützung von vereinfachtermultipart/form-data
-Unterstützung - Kompatible Verarbeitung von Beziehungsschlüsseln ohne Beachtung der Groß-/Kleinschreibung
- Hinzufügen des
-Resume
-Parameters zu Web-Cmdlets
„Invoke-RestMethod“ gibt nützliche Informationen zurück, wenn keine Daten zurückgegeben werden
Wenn eine API nur null
zurückgibt, hat Invoke-RestMethod
dies als die Zeichenfolge "null"
statt $null
serialisiert. Diese Änderung korrigiert die Logik in Invoke-RestMethod
, um das gültige JSON-Literal mit Einzelwert null
ordnungsgemäß als $null
zu serialisieren.
Web-Cmdlets geben eine Warnung aus, wenn -Credential
über nicht verschlüsselte Verbindungen gesendet wird
Bei der Verwendung von HTTP werden Inhalte mit Kennwörtern als Klartext gesendet. Durch diese Änderung wird dies standardmäßig nicht zugelassen, außerdem wird ein Fehler zurückgegeben, wenn Anmeldeinformationen auf unsichere Weise weitergeleitet werden. Die Benutzer können dies umgehen, indem Sie den Parameter -AllowUnencryptedAuthentication
verwenden.
Dafür sorgen, dass -OutFile
-Parameter in Web-Cmdlets wie -LiteralPath
funktionieren
Ab PowerShell 7.1 funktioniert der OutFile-Parameter der Web-Cmdlets wie LiteralPath und verarbeitet keine Platzhalter.
API-Änderungen
Entfernung der AddTypeCommandBase
-Klasse
Die AddTypeCommandBase
-Klasse wurde aus Add-Type
entfernt, um die Leistung zu verbessern. Diese Klasse wird nur vom Cmdlet Add-Type
verwendet, sodass es keine Auswirkungen auf die Benutzer geben sollte.
VisualBasic
als unterstützte Sprache in Add-Type entfernt
Bisher konnte Visual Basic-Code mit dem Add-Type
-Cmdlet kompiliert werden. Visual Basic wurde jedoch nur selten mit Add-Type
verwendet. Daher wurde diese Funktion nun entfernt, um die Größe von PowerShell zu reduzieren.
Entfernung der Unterstützung von RunspaceConfiguration
Zuvor konnten Sie bei der programmgesteuerten Erstellung eines PowerShell-Runspaces mithilfe der API die veraltete Klasse RunspaceConfiguration
oder die neueren InitialSessionState
-Klassen verwenden. Durch diese Änderung wurde die Unterstützung für RunspaceConfiguration
entfernt, sodass nur noch InitialSessionState
unterstützt wird.
CommandInvocationIntrinsics.InvokeScript
bindet Argumente an $input
anstatt an $args
Die falsche Position eines Parameters führte dazu, dass die Argumente als Eingabe statt als Argumente übergeben wurden.
Entfernung von ClrVersion
- und BuildVersion
-Eigenschaften aus $PSVersionTable
Die ClrVersion
-Eigenschaft von $PSVersionTable
ist bei CoreCLR nicht hilfreich. Endbenutzer sollten diesen Wert nicht verwenden, um die Kompatibilität zu bestimmen.
Die BuildVersion
-Eigenschaft war an die Windows-Buildversion gebunden, die auf Nicht-Windows-Plattformen nicht verfügbar ist. Verwenden Sie die GitCommitId
-Eigenschaft, um die genaue Buildversion von PowerShell abzurufen.
Implementierung der Analyse von Unicode-Escapesequenzen
`u####
oder `u{####}
wird in das entsprechende Unicode-Zeichen konvertiert. Verwenden Sie das Hochkommazeichen ( ``u
), um ein Literal ( `u
) auszugeben.
Problem mit der Bindung von Parametern mit ValueFromRemainingArguments
in PowerShell-Funktionen
ValueFromRemainingArguments
gibt nun die Werte als Array statt als Einzelwert, der ein Array darstellt, zurück.
Verwendung von CommandTypes.Workflow
und WorkflowInfoCleaned
bereinigt
Bereinigen Sie Code in Bezug auf die Verwendung von CommandTypes.Workflow
und WorkflowInfo
in System.Management.Automation.
Diese geringfügigen Breaking Changes betreffen hauptsächlich den Code der Hilfeanbieter.
- Ändern Sie die öffentlichen Konstruktoren von
WorkflowInfo
in „internal“. Wir unterstützen den Workflow nicht mehr, sodass es sinnvoll ist, das Erstellen vonWorkflow
-Instanzen zu unterbinden. - Entfernen Sie den Typ System.Management.Automation.DebugSource, da er nur für das Debuggen von Workflows verwendet wird.
- Entfernen Sie die Überladung von
SetParent
aus dem Debugger der abstrakten Klasse, der nur für das Debuggen von Workflows verwendet wird. - Entfernen Sie dieselbe Überladung von
SetParent
aus der abgeleiteten Klasse RemotingJobDebugger.
Zurückgegebenes Ergebnis nicht in PSObject
umschließen, wenn ScriptBlock
in einen Delegaten konvertiert wird
Wenn ScriptBlock
in einen Delegattyp konvertiert wird, der im C#-Kontext verwendet werden soll, führt das Umschließen des Ergebnisses in PSObject
zu unnötigen Problemen:
- Wenn der Wert in den Rückgabetyp des Delegaten konvertiert wird, wird
PSObject
im Wesentlichen entpackt.PSObject
ist daher nicht erforderlich. - Wenn der Rückgabetyp des Delegaten
object
ist, wird er inPSObject
umschlossen, was die Verwendung in C#-Code erschwert.
Nach dieser Änderung entspricht das zurückgegebene Objekt dem zugrunde liegenden Objekt.
Unterstützung für das Remoting
PowerShell-Remoting (PSRP) mit WinRM auf Unix-Plattformen erfordert NTLM/Negotiate oder die Standardauthentifizierung über HTTPS. PSRP unter macOS unterstützt nur die Standardauthentifizierung über HTTPS. Die Kerberos-basierte Authentifizierung wird für Nicht-Windows-Plattformen nicht unterstützt.
PowerShell unterstützt das PowerShell-Remoting (PSRP) ebenfalls auf allen Plattformen (Windows, macOS, Linux) über SSH. Weitere Informationen finden Sie unter SSH-Remoting in PowerShell.
PowerShell Direct für Container versucht zunächst pwsh
zu verwenden
PowerShell Direct ist eine Funktion von PowerShell und Hyper-V, mit der Sie ohne Netzwerkverbindung oder einem anderen Remoteverwaltungsdienst eine Verbindung zu einem virtuellen Hyper-V-Computer oder Container herstellen können.
Bisher wurde die Verbindung von PowerShell Direct mithilfe der integrierten Windows PowerShell-Instanz im Container hergestellt. Nun versucht PowerShell Direct zunächst, verfügbare pwsh.exe
-Dateien der PATH
-Umgebungsvariable dafür zu verwenden. Ist pwsh.exe
nicht verfügbar, greift PowerShell Direct wieder auf powershell.exe
zurück.
Enable-PSRemoting
erstellt jetzt separate Remotingendpunkte für Vorschauversionen
Enable-PSRemoting
erstellt jetzt zwei Konfigurationen für Remotesitzungen:
- Eine für die Hauptversion von PowerShell, Beispiel:
PowerShell.6
. Auf diesen Endpunkt kann nach geringfügigen Aktualisierungen als systemweite Sitzungskonfiguration von PowerShell 6 zurückgegriffen werden. - Eine versionsspezifische Sitzungskonfiguration, z.B.
PowerShell.6.1.0
.
Dieses Verhalten ist hilfreich, wenn Sie mehrere Versionen von PowerShell 6 auf einem Computer installiert und zugänglich haben möchten.
Darüber hinaus verfügen Vorschauversionen von PowerShell nun über eigene Remotesitzungskonfigurationen, wenn Sie das Enable-PSRemoting
-Cmdlet ausgeführt haben:
C:\WINDOWS\system32> Enable-PSRemoting
Die Ausgabe sieht möglicherweise anders aus, wenn Sie nicht zuvor WinRM eingerichtet haben.
WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.
In diesem Fall werden möglicherweise separate PowerShell-Sitzungskonfigurationen für die Vorschau und stabile Builds von PowerShell 6 sowie für jede einzelne Version angezeigt.
Get-PSSessionConfiguration
Name : PowerShell.6.2-preview.1
PSVersion : 6.2
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
Name : PowerShell.6-preview
PSVersion : 6.2
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
Name : powershell.6
PSVersion : 6.1
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
Name : powershell.6.1.0
PSVersion : 6.1
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
Für SSH unterstützte user@host:port
-Syntax
SSH-Clients unterstützen in der Regel eine Verbindungszeichenfolge im Format user@host:port
. Durch das Hinzufügen von SSH als Protokoll für PowerShell-Remoting ist nun Unterstützung für dieses Format der Verbindungszeichenfolge enthalten:
Enter-PSSession -HostName fooUser@ssh.contoso.com:2222
Deaktivieren von Telemetrie nur mit einer Umgebungsvariable
PowerShell sendet beim Starten grundlegende Telemetriedaten an Microsoft. Diese enthalten den Namen und die Version des Betriebssystems sowie die Version von PowerShell. Dadurch wird erkennbar, in welchen Umgebungen PowerShell verwendet wird und welche neuen Funktionen und Problembehebungen Vorrang haben sollten.
Wenn Sie diese Telemetriedaten nicht senden möchten, legen Sie die Umgebungsvariable POWERSHELL_TELEMETRY_OPTOUT
auf true
, yes
oder 1
fest. Die Datei DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY
wird zum Deaktivieren der Telemetrie nicht mehr unterstützt.