Dela via

Skillnader mellan Windows PowerShell 5.1 och PowerShell 7.x

Windows PowerShell 5.1 bygger på .NET Framework v4.5. Med lanseringen av PowerShell 6.0 blev PowerShell ett öppen källkod projekt som bygger på .NET Core 2.0. Genom att flytta från .NET Framework till .NET Core kunde PowerShell bli en plattformsoberoende lösning. PowerShell körs i Windows, macOS och Linux.

Det finns få skillnader i PowerShell-språket mellan Windows PowerShell och PowerShell. De mest anmärkningsvärda skillnaderna är tillgängligheten och beteendet för PowerShell-cmdletar mellan Windows- och icke-Windows-plattformar och de ändringar som beror på skillnaderna mellan .NET Framework och .NET Core.

Den här artikeln sammanfattar de betydande skillnaderna och de icke-bakåtkompatibla ändringarna mellan Windows PowerShell och den aktuella versionen av PowerShell. Den här sammanfattningen innehåller inte nya funktioner eller cmdletar som har lagts till. Den här artikeln beskriver inte heller vad som har ändrats mellan versioner. Målet med den här artikeln är att presentera det aktuella tillståndet för PowerShell och hur det skiljer sig från Windows PowerShell. En detaljerad beskrivning av ändringar mellan versioner och tillägg av nya funktioner finns i artiklarna Nyheter för varje version.

.NET Framework jämfört med .NET Core

PowerShell i Linux och macOS använder .NET Core, som är en delmängd av det fullständiga .NET Framework i Microsoft Windows. Detta är viktigt eftersom PowerShell ger direkt åtkomst till de underliggande ramverkstyperna och metoderna. Det innebär att skript som körs i Windows kanske inte körs på plattformar som inte är Windows på grund av skillnaderna i ramverken. Mer information om ändringar i .NET Core finns i Icke-bakåtkompatibla ändringar för migrering från .NET Framework till .NET Core.

Varje ny version av PowerShell bygger på en nyare version av .NET. Det kan finnas icke-bakåtkompatibla ändringar i .NET som påverkar PowerShell.

  • PowerShell 7.5 – Bygger på .NET 9.0
  • PowerShell 7.4 – Bygger på .NET 8.0
  • PowerShell 7.3 – Bygger på .NET 7.0
  • PowerShell 7.2 (LTS-current) – Byggd på .NET 6.0 (LTS-current)
  • PowerShell 7.1 – Bygger på .NET 5.0
  • PowerShell 7.0 (LTS) – byggd på .NET Core 3.1 (LTS)
  • PowerShell 6.2 – Bygger på .NET Core 2.1
  • PowerShell 6.1 – Bygger på .NET Core 2.1
  • PowerShell 6.0 – Bygger på .NET Core 2.0

Med tillkomsten av .NET Standard 2.0 kan PowerShell läsa in många traditionella Windows PowerShell-moduler utan ändringar. Dessutom innehåller PowerShell 7 en Windows PowerShell-kompatibilitetsfunktion som gör att du kan använda Windows PowerShell-moduler som fortfarande kräver det fullständiga ramverket.

Mer information finns i:

Var medveten om ändringar i .NET-metoden

Även om .NET-metodändringar inte är specifika för PowerShell kan de påverka dina skript, särskilt om du anropar .NET-metoder direkt. Det kan också finnas nya överlagringar för konstruktorer. Detta kan påverka hur du skapar objekt med hjälp av New-Object eller [type]::new() metoden.

.NET har till exempel lagt till överlagringar i metoden [System.String]::Split() som inte är tillgänglig i .NET Framework 4.5. I följande lista visas överlagringarna för metoden Split() som är tillgänglig i Windows PowerShell 5.1:

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)

I följande lista visas överlagringarna för metoden som Split() är tillgänglig i PowerShell 7:

"".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)

I Windows PowerShell 5.1 kan du skicka en teckenmatris (char[]) till Split() metoden som en string. Metoden delar upp målsträngen vid varje förekomst av ett tecken i matrisen. Följande kommando delar upp målsträngen i Windows PowerShell 5.1, men inte i PowerShell 7:

# PowerShell 7 example
"1111p2222q3333".Split('pq')

1111p2222q3333

Om du vill binda till rätt överlagring måste du skrivasträngen till en teckenmatris:

# PowerShell 7 example
"1111p2222q3333".Split([char[]]'pq')

1111
2222
3333

Moduler som inte längre levereras med PowerShell

Av olika kompatibilitetsskäl ingår inte längre följande moduler i PowerShell.

  • ISE
  • Microsoft.PowerShell.LocalAccounts
  • Microsoft.PowerShell.ODataUtils
  • Microsoft.PowerShell.Operation.Validation
  • PSScheduledJob
  • PSWorkflow
  • PSWorkflowUtility

PowerShell-arbetsflöde

PowerShell Workflow är en funktion i Windows PowerShell som bygger på Windows Workflow Foundation (WF) som gör det möjligt att skapa robusta runbooks för långvariga eller parallelliserade uppgifter.

På grund av bristen på stöd för Windows Workflow Foundation i .NET Core tog vi bort PowerShell-arbetsflödet från PowerShell.

I framtiden vill vi aktivera intern parallellitet/samtidighet i PowerShell-språket utan att behöva PowerShell-arbetsflöde.

Om det finns ett behov av att använda kontrollpunkter för att återuppta ett skript efter att operativsystemet har startats om rekommenderar vi att du använder Schemaläggaren för att köra ett skript vid operativsystemstart, men skriptet skulle behöva behålla sitt eget tillstånd (som att spara det i en fil).

Cmdletar som tagits bort från PowerShell

För de moduler som ingår i PowerShell togs följande cmdletar bort från PowerShell av olika kompatibilitetsskäl eller användning av API:er som inte stöds.

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-cmdletar

Följande WMI v1-cmdletar har tagits bort från PowerShell:

  • Register-WmiEvent
  • Set-WmiInstance
  • Invoke-WmiMethod
  • Get-WmiObject
  • Remove-WmiObject

CimCmdlets-cmdletarna (även kallat WMI v2) utför samma funktion och ger nya funktioner och en omdesignad syntax.

New-WebServiceProxy cmdleten har tagits bort

.NET Core stöder inte Windows Communication Framework, som tillhandahåller tjänster för användning av SOAP-protokollet. Den här cmdleten har tagits bort eftersom den kräver SOAP.

*-Transaction cmdletar har tagits bort

Dessa cmdletar hade mycket begränsad användning. Beslutet fattades att upphöra med stödet till dem.

  • Complete-Transaction
  • Get-Transaction
  • Start-Transaction
  • Undo-Transaction
  • Use-Transaction

*-EventLog Cmdlets

På grund av användningen av API:er *-EventLog som inte stöds har cmdletarna tagits bort från PowerShell. Get-WinEvent och New-WinEvent är tillgängliga för att hämta och skapa händelser i Windows.

Cmdletar som använder Windows Presentation Framework (WPF)

.NET Core 3.1 har lagt till stöd för WPF, så versionen av PowerShell 7.0 återställde följande Windows-specifika funktioner:

  • Cmdleten Show-Command
  • Cmdleten Out-GridView
  • Parametern ShowWindow för Get-Help

Ändringar i PowerShell Desired State Configuration (DSC)

Invoke-DscResource återställdes som en experimentell funktion i PowerShell 7.0.

Från och med PowerShell 7.2 har modulen PSDesiredStateConfiguration tagits bort från PowerShell och har publicerats till PowerShell-galleriet. Mer information finns i meddelandet i PowerShell Team-bloggen.

Körbara PowerShell-ändringar

powershell.exe har bytt namn till pwsh.exe

Det binära namnet på PowerShell har ändrats från powershell(.exe) till pwsh(.exe). Den här ändringen ger ett deterministiskt sätt för användare att köra PowerShell på datorer och stödja installationer sida vid sida av Windows PowerShell och PowerShell.

Ytterligare ändringar i pwsh(.exe) från powershell.exe:

  • Ändrade den första positionsparametern från -Command till -File. Den här ändringen åtgärdar användningen av #! (även kallat shebang) i PowerShell-skript som körs från icke-PowerShell-gränssnitt på plattformar som inte är Windows-plattformar. Det innebär också att du kan köra kommandon som pwsh foo.ps1 eller pwsh fooScript utan att -Fileange . Den här ändringen kräver dock att du uttryckligen anger -c eller -Command när du försöker köra kommandon som pwsh.exe -Command Get-Command.
  • pwsh accepterar växeln -i (eller -Interactive) för att indikera ett interaktivt gränssnitt. Detta gör att PowerShell kan användas som standardgränssnitt på Unix-plattformar.
  • Parametrarna -ImportSystemModules har tagits bort och -PSConsoleFile från pwsh.exe.
  • Ändrad pwsh -version och inbyggd hjälp för pwsh.exe att anpassa till andra inbyggda verktyg.
  • Ogiltiga argumentfelmeddelanden för -File och -Command slutkoder som överensstämmer med Unix-standarder
  • Parametern har lagts till -WindowStyle i Windows. På samma sätt är paketbaserade installationsuppdateringar på icke-Windows-plattformar uppdateringar på plats.

Det förkortade namnet överensstämmer också med namngivning av gränssnitt på plattformar som inte är Windows-plattformar.

Stöd för att köra ett PowerShell-skript med bool-parameter

Tidigare använde du pwsh.exe för att köra ett PowerShell-skript med hjälp av -File inget sätt att skicka $true/$false som parametervärden. Stöd för $true/$false som tolkade värden för parametrar har lagts till. Switch-värden stöds också.

Förbättrad bakåtkompatibilitet med Windows PowerShell

För Windows läggs en ny växelparameter UseWindowsPowerShell till i Import-Module. Den här växeln skapar en proxymodul i PowerShell 7 som använder en lokal Windows PowerShell-process för att implicit köra alla cmdletar som finns i modulen. Mer information finns i Import-Module.

Mer information om vilka Microsoft-moduler som fungerar med PowerShell 7.0 finns i tabellen Modulkompatibilitet.

Microsoft Update-stöd för Windows

PowerShell 7.2 har lagt till stöd för Microsoft Update. När du aktiverar den här funktionen får du de senaste PowerShell 7-uppdateringarna i ditt traditionella Hanteringsflöde för Windows Update (WU), oavsett om det är med Windows Update för företag, WSUS, SCCM eller den interaktiva WU-dialogrutan i Inställningar.

PowerShell 7.2 MSI-paketet innehåller följande kommandoradsalternativ:

  • USE_MU – Den här egenskapen har två möjliga värden:
    • 1 (standard) – Väljer att uppdatera via Microsoft Update eller WSUS
    • 0 – Välj inte att uppdatera via Microsoft Update eller WSUS
  • ENABLE_MU
    • 1(standard) – Väljer att använda Microsoft Update den automatiska Uppdateringar eller Windows Update
    • 0– Välj inte att använda Microsoft Update den automatiska Uppdateringar eller Windows Update

Motorändringar

Stöd för PowerShell som standard unix-gränssnitt

I Unix är det en konvention för gränssnitt att acceptera -i för ett interaktivt gränssnitt och många verktyg förväntar sig det här beteendet (script till exempel och när du anger PowerShell som standardgränssnitt) och anropar gränssnittet med växeln -i . Den här ändringen bryter in som -i tidigare kunde användas som kort hand för att matcha -inputformat, som nu måste vara -in.

Anpassade snapin-moduler

PowerShell-snapin-moduler är en föregångare till PowerShell-moduler som inte har någon omfattande implementering i PowerShell-communityn .

På grund av komplexiteten i att stödja snapin-moduler och deras brist på användning i communityn stöder vi inte längre anpassade snapin-moduler i PowerShell.

Experimentella funktionsflaggor

PowerShell 6.2-aktiverat stöd för experimentella funktioner. På så sätt kan PowerShell-utvecklare leverera nya funktioner och få feedback innan designen är klar. På så sätt undviker vi att göra icke-bakåtkompatibla ändringar när designen utvecklas.

Använd Get-ExperimentalFeature för att hämta en lista över tillgängliga experimentella funktioner. Du kan aktivera eller inaktivera dessa funktioner med Enable-ExperimentalFeature och Disable-ExperimentalFeature.

Läs in sammansättningen från modulbassökvägen innan du försöker läsa in från GAC

Tidigare, när en binär modul har modulsammansättningen i GAC, läste vi in sammansättningen från GAC innan vi försökte läsa in den från modulbassökvägen.

Hoppa över null-elementkontroll för samlingar med en värdetypselementtyp

För parametern Mandatory och ValidateNotNull attributen ValidateNotNullOrEmpty hoppar du över null-elementkontrollen om samlingens elementtyp är värdetyp.

Bevara $? för ParenExpression, SubExpression och ArrayExpression

Den här PR:n ändrar hur vi kompilerar subpipelines (...), underuttryck $(...) och matrisuttryck @() så att det $? inte är automatiskt sant. I stället beror värdet för $? på resultatet av den pipeline eller de instruktioner som körs.

Korrigering $? som inte ska vara $false när det interna kommandot skriver till stderr

$? är inte inställt på $false när det interna kommandot skriver till stderr. Det är vanligt att interna kommandon skrivs till stderr utan avsikt att indikera ett fel. $? anges till $false endast när det interna kommandot har en slutkod som inte är noll.

Påverka $ErrorActionPreference inte stderr utdata från interna kommandon

Det är vanligt att interna kommandon skrivs till stderr utan avsikt att indikera ett fel. Med den här ändringen stderr registreras fortfarande utdata i ErrorRecord-objekt , men körningen gäller $ErrorActionPreference inte längre om ErrorRecord kommer från ett internt kommando.

Ändra $OutputEncoding om du vill använda UTF-8 NoBOM kodning i stället för ASCII

Den tidigare kodningen, ASCII (7-bitars), skulle resultera i felaktig ändring av utdata i vissa fall. Standardinställningen UTF-8 NoBOM bevarar Unicode-utdata med en kodning som stöds av de flesta verktyg och operativsystem.

Förena cmdletar med parameter som -Encoding ska vara av typen System.Text.Encoding

Värdet -Encoding Byte har tagits bort från cmdletarna för filsystemprovidern. En ny parameter, -AsByteStream, används nu för att ange att en byteström krävs som indata eller att utdata är en ström med byte.

Ändra New-ModuleManifest kodning till UTF8NoBOM på plattformar som inte är Windows-plattformar

New-ModuleManifest Tidigare skapades psd1 manifest i UTF-16 med BOM, vilket skapar ett problem för Linux-verktyg. Den här icke-bakåtkompatibla ändringen ändrar kodningen av till UTF (ingen strukturliste) på plattformar som inte är Windows.This breaking change changes the encoding of New-ModuleManifest to be UTF (no BOM) in non-Windows platforms.

Ta bort AllScope från de flesta standardalias

För att påskynda skapande AllScope av omfång har tagits bort från de flesta standardalias. AllScope lämnades för några vanliga alias där sökningen var snabbare.

-Verbose och -Debug åsidosätter inte längre $ErrorActionPreference

Tidigare, om -Verbose eller -Debug har angetts, överskrör det beteendet $ErrorActionPreferenceför . Med den här ändringen -Verbose och -Debug påverkar inte längre beteendet $ErrorActionPreferenceför .

Parametern -Debug ställer också in $DebugPreference på Fortsätt i stället för Fråga.

Gör $PSCulture konsekvent ändringar i sessionskulturen

I Windows PowerShell cachelagras det aktuella kulturvärdet, vilket kan göra att värdet inte synkroniseras med kulturen när sessionen startas. Det här cachelagringsbeteendet har åtgärdats i PowerShell Core.

Tillåt uttryckligen angiven namngiven parameter att ersätta samma från hashtable-splatting

Med den här ändringen flyttas de namngivna parametrarna från splatting till slutet av parameterlistan så att de är bundna när alla uttryckligen angivna namngivna parametrar är bundna. Parameterbindning för enkla funktioner utlöser inget fel när det inte går att hitta en angiven namngiven parameter. Okända namngivna parametrar är bundna till parametern $args för den enkla funktionen. Om du flyttar splatting till slutet av argumentlistan ändras ordningen som parametrarna visas i $args.

Till exempel:

function SimpleTest {
    param(
        $Name,
        $Path
    )
    "Name: $Name; Path: $Path; Args: $args"
}

I det tidigare beteendet är MyPath inte bundet till -Path eftersom det är det tredje argumentet i argumentlistan. ## Så det slutar med att det fylls i "$args" tillsammans med Blah = "World"

PS> $hash = @{ Name = "Hello"; Blah = "World" }
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: ; Args: -Blah: World MyPath

Med den här ändringen flyttas argumenten från @hash till slutet av argumentlistan. MyPath blir det första argumentet i listan, så det är bundet till -Path.

PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World

Språkändringar

Operatorn Null-coalescing ??

Operatorn ?? null-coalescing returnerar värdet för dess vänstra operand om den inte är null. Annars utvärderas den högra operanden och dess resultat returneras. Operatorn ?? utvärderar inte sin högra operand om den vänstra operanden utvärderas till icke-null.

$x = $null
$x ?? 100

100

I följande exempel utvärderas inte den högra operanden.

[string] $todaysDate = '1/10/2020'
$todaysDate ?? (Get-Date).ToShortDateString()

1/10/2020

Null-sammanslutande tilldelningsoperator ??=

Tilldelningsoperatorn ??= null-coalescing tilldelar endast värdet för sin högra operande till sin vänstra operande om den vänstra operanden utvärderas till null. Operatorn ??= utvärderar inte sin högra operand om den vänstra operanden utvärderas till icke-null.

$x = $null
$x ??= 100
$x

100

I följande exempel utvärderas inte den högra operanden.

[string] $todaysDate = '1/10/2020'
$todaysDate ??= (Get-Date).ToShortDateString()

1/10/2020

Null-villkorsstyrda operatorer

Kommentar

Den här funktionen har flyttats från experimentell till mainstream i PowerShell 7.1.

En null-villkorsoperator tillämpar endast en medlemsåtkomst, ?., eller elementåtkomst, ?[]på dess operand om operanden utvärderas till icke-null. Annars returneras null.

Eftersom PowerShell kan ? ingå i variabelnamnet krävs en formell specifikation av variabelnamnet för att använda dessa operatorer. Därför måste du använda {} runt variabelnamnen som ${a} eller när ? är en del av variabelnamnet ${a?}.

I följande exempel returneras värdet för PropName .

$a = @{ PropName = 100 }
${a}?.PropName

100

Följande exempel returnerar null utan att försöka komma åt medlemsnamnet PropName.

$a = $null
${a}?.PropName

På samma sätt returneras värdet för elementet.

$a = 1..10
${a}?[0]

1

Och när operand är null används inte elementet och null returneras.

$a = $null
${a}?[0]

Kommentar

Syntaxen för variabelnamn för ${<name>} bör inte förväxlas med $() underuttrycksoperatorn. Mer information finns i avsnittet Variabelnamn i about_Variables.

Operatorn för jobbkontroll har lagts till &

Om du placerar & i slutet av en pipeline körs pipelinen som ett PowerShell-jobb. När en pipeline har bakgrund returneras ett jobbobjekt. När pipelinen körs som ett jobb kan alla standard-cmdletar *-Job användas för att hantera jobbet. Variabler (ignorerar processspecifika variabler) som används i pipelinen kopieras automatiskt till jobbet så Copy-Item $foo $bar & fungerar bara. Jobbet körs också i den aktuella katalogen i stället för användarens hemkatalog.

Nya metoder/egenskaper på PSCustomObject

Vi har lagt till nya metoder och egenskaper i PSCustomObject. PSCustomObject innehåller nu en Count/Length egenskap som andra objekt.

$PSCustomObject = [pscustomobject]@{foo = 1}

$PSCustomObject.Length

1

$PSCustomObject.Count

1

Det här arbetet omfattar ForEach även metoder som Where gör att du kan använda och filtrera objekt PSCustomObject :

$PSCustomObject.ForEach({$_.foo + 1})

2

$PSCustomObject.Where({$_.foo -gt 0})

foo
---
  1

Konverteringar från PSMethod till Ombud

Du kan konvertera en PSMethod till ett ombud. På så sätt kan du göra saker som att skicka PSMethod[M]::DoubleStrLen som ett ombudsvärde till [M]::AggregateString:

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)

Beteende för strängjämförelse har ändrats i PowerShell 7.1

PowerShell 7.1 bygger på .NET 5.0, som introducerade följande icke-bakåtkompatibla ändring:

Från och med .NET 5.0 ignorerar kulturvarianta strängjämförelser icke-utskriftskontrolltecken.

Följande två strängar anses till exempel vara identiska:

# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"

True

Nya cmdletar

Ny Get-Uptime-cmdlet

Cmdleten Get-Uptime returnerar den tid som förflutit sedan den senaste starten av operativsystemet. Cmdleten introducerades i PowerShell 6.0.

Ny cmdlet för ta bort alias

Cmdleten Remove-Alias tar bort ett alias från den aktuella PowerShell-sessionen. Cmdleten introducerades i PowerShell 6.0.

Ny cmdlet Remove-Service

Cmdleten Remove-Service tar bort en Windows-tjänst i registret och i tjänstdatabasen. Cmdleten Remove-Service introducerades i PowerShell 6.0.

Nya Markdown-cmdletar

Markdown är en standard för att skapa läsbara klartextdokument med grundläggande formatering som kan återges i HTML.

Följande cmdletar har lagts till i PowerShell 6.1:

  • ConvertFrom-Markdown – Konvertera innehållet i en sträng eller en fil till ett MarkdownInfo-objekt .
  • Get-MarkdownOption – Returnerar de aktuella färgerna och formaten som används för att återge Markdown-innehåll i konsolen.
  • Set-MarkdownOption – Anger de färger och format som används för att återge Markdown-innehåll i konsolen.
  • Show-Markdown – Visar Markdown-innehåll i konsolen eller som HTML

Ny Test-Json-cmdlet

Cmdleten Test-Json testar om en sträng är ett giltigt JSON-dokument (JavaScript Object Notation) och kan även verifiera JSON-dokumentet mot ett angivet schema.

Den här cmdleten introducerades i PowerShell 6.1

Nya cmdletar för att stödja experimentella funktioner

Följande cmdletar har lagts till i PowerShell 6.2 för att stödja experimentella funktioner.

Ny cmdlet för kopplingssträng

Cmdleten Join-String kombinerar objekt från pipelinen till en enda sträng. Den här cmdleten lades till i PowerShell 6.2.

Ny vy – ConciseView och cmdleten Get-Error

PowerShell 7.0 förbättrar visningen av felmeddelanden för att förbättra läsbarheten för interaktiva fel och skriptfel med en ny standardvy, ConciseView. Vyerna kan väljas av användaren via inställningsvariabeln $ErrorView.

Om ett fel inte kommer från ett skript- eller parsningsfel med ConciseView är det ett felmeddelande med en rad:

Get-Childitem -Path c:\NotReal

Get-ChildItem: Cannot find path 'C:\NotReal' because it does not exist

Om felet inträffar under skriptkörningen eller är ett parsningsfel returnerar PowerShell ett felmeddelande med flera rader som innehåller felet, en pekare och ett felmeddelande som visar var felet finns på den raden. Om terminalen inte stöder ANSI-färgutrymningssekvenser (VT100) visas inte färger.

Standardvyn i PowerShell 7 är ConciseView. Den tidigare standardvyn var NormalView och du kan välja detta genom att ange inställningsvariabeln $ErrorView.

$ErrorView = 'NormalView' # Sets the error view to NormalView
$ErrorView = 'ConciseView' # Sets the error view to ConciseView

Kommentar

En ny egenskap ErrorAccentColor läggs till för att $Host.PrivateData ge stöd för att ändra accentfärgen för felmeddelandet.

Den nya Get-Errorcmdleten ger en fullständig detaljerad vy över det fullständigt kvalificerade felet när du vill. Som standard visar cmdleten fullständig information, inklusive inre undantag, om det senaste felet som inträffade.

Cmdleten Get-Error stöder indata från pipelinen med hjälp av den inbyggda variabeln $Error. Get-Error visar alla piped-fel.

$Error | Get-Error

Cmdleten Get-Error stöder parametern Newest så att du kan ange hur många fel från den aktuella sessionen som du vill visa.

Get-Error -Newest 3 # Displays the lst three errors that occurred in the session

Mer information finns i Get-Error.

Cmdlet-ändringar

Parallell körning har lagts till i ForEach-Object

Från och med PowerShell 7.0 har cmdleten ForEach-Object , som itererar objekt i en samling, nu inbyggd parallellitet med den nya parallella parametern.

Som standard använder parallella skriptblock den aktuella arbetskatalogen för anroparen som startade de parallella uppgifterna.

Det här exemplet hämtar 50 000 loggposter från 5 systemloggar på en lokal Windows-dator:

$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

Parametern Parallel anger det skriptblock som körs parallellt för varje indataloggnamn.

Den nya parametern ThrottleLimit begränsar antalet skriptblock som körs parallellt vid en viss tidpunkt. Standardinställningen är 5.

Använd variabeln $_ för att representera det aktuella indataobjektet i skriptblocket. Använd omfånget $using: för att skicka variabelreferenser till skriptblocket som körs.

Mer information finns i ForEach-Object.

Sök efter system32 kompatibla inbyggda moduler i Windows

I Windows 10 1809-uppdateringen och Windows Server 2019 uppdaterade vi ett antal inbyggda PowerShell-moduler för att markera dem som kompatibla med PowerShell.

När PowerShell startas ingår $windir\System32 det automatiskt som en del av PSModulePath miljövariabeln. Den exponerar dock bara moduler till Get-Module och om den CompatiblePSEdition är markerad som kompatibel med CoreImport-Module .

Du kan åsidosätta det här beteendet för att visa alla moduler med hjälp av switchparametern -SkipEditionCheck . Vi har också lagt till en PSEdition egenskap i tabellutdata.

-lp alias för alla -LiteralPath parametrar

Vi skapade ett standardparameteralias -lp för alla inbyggda PowerShell-cmdletar som har en -LiteralPath parameter.

Åtgärda Get-Item -LiteralPath a*b om a*b det faktiskt inte finns något fel för att returnera felet

Tidigare skulle -LiteralPath ett jokertecken behandla det på samma sätt som -Path och om jokertecknet inte hittade några filer skulle det tyst avslutas. Rätt beteende bör vara att -LiteralPath är literal, så om filen inte finns bör det fel. Ändring är att behandla jokertecken som används med -Literal som literal.

Ange arbetskatalog till aktuell katalog i Start-Job

Cmdleten Start-Job använder nu den aktuella katalogen som arbetskatalog för det nya jobbet.

Ta bort -Protocol från *-Computer cmdletar

På grund av problem med RPC-fjärrkommunikation i CoreFX (särskilt på icke-Windows-plattformar) och säkerställa en konsekvent fjärrkommunikationsupplevelse i PowerShell, togs parametern -Protocol bort från \*-Computer cmdletarna. DCOM stöds inte längre för fjärrkommunikation. Följande cmdletar stöder endast WSMAN-fjärrkommunikation:

  • Rename-Computer
  • Restart-Computer
  • Stop-Computer

Ta bort -ComputerName från *-Service cmdletar

För att uppmuntra till konsekvent användning av PSRP togs parametern -ComputerName bort från *-Service cmdletar.

Korrigering Get-Content -Delimiter för att inte inkludera avgränsare i de returnerade raderna

Tidigare var utdata vid användning Get-Content -Delimiter inkonsekventa och obekväma eftersom det krävde ytterligare bearbetning av data för att ta bort avgränsare. Den här ändringen tar bort avgränsare i returnerade rader.

Ändringar i Format-Hex

Parametern -Raw är nu en "no-op" (eftersom den inte gör någonting). Framöver visas alla utdata med en sann representation av tal som innehåller alla byte för sin typ. Det här är vad parametern -Raw gjorde före den här ändringen.

Stavfelskorrigering i Get-ComputerInfo-egenskapsnamn

BiosSerialNumber stavningsfel BiosSeralNumber och har ändrats till rätt stavning.

Lägg till Get-StringHash och Get-FileHash cmdletar

Den här ändringen är att vissa hash-algoritmer inte stöds av CoreFX, därför är de inte längre tillgängliga:

  • MACTripleDES
  • RIPEMD160

Lägg till validering på Get-* cmdletar där skickande $null returnerar alla objekt i stället för fel

Om du skickar $null till något av följande genereras nu ett fel:

  • 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

Lägg till stöd för W3C Extended Log File Format i Import-Csv

Tidigare kan cmdleten Import-Csv inte användas för att direkt importera loggfilerna i W3C utökat loggformat och ytterligare åtgärder krävs. Med den här ändringen stöds W3C-utökat loggformat.

Import-CsvPSTypeNames gäller vid import när typinformation finns i CSV

Tidigare behöll objekt som exporterades med Export-CSV importerade med ConvertFrom-Csv TypeInformation inte typinformationen. Den här ändringen lägger till typinformationen till PSTypeNames medlemmen om den är tillgänglig från CSV-filen.

-NoTypeInformation är standardinställningen på Export-Csv

Tidigare skulle cmdleten Export-CSV mata ut en kommentar som den första raden som innehåller objektets typnamn. Ändringen exkluderar typinformationen som standard eftersom den inte förstås av de flesta CSV-verktyg. Den här ändringen gjordes för att åtgärda kundfeedback.

Använd -IncludeTypeInformation för att behålla det tidigare beteendet.

Tillåt * att användas i registersökvägen för Remove-Item

Tidigare skulle -LiteralPath ett jokertecken behandla det på samma sätt som -Path och om jokertecknet inte hittade några filer skulle det tyst avslutas. Rätt beteende bör vara att -LiteralPath är literal, så om filen inte finns bör det fel. Ändring är att behandla jokertecken som används med -Literal som literal.

Gruppobjekt sorterar nu grupperna

Som en del av prestandaförbättringen Group-Object returnerar nu en sorterad lista över grupperna. Även om du inte bör förlita dig på ordningen kan du brytas av den här ändringen om du vill ha den första gruppen. Vi beslutade att den här prestandaförbättringen var värd ändringen eftersom effekten av att vara beroende av tidigare beteende är låg.

Standardavvikelse i Measure-Object

Utdata från Measure-Object och med nu innehåller en StandardDeviation egenskap.

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 nu har parametern Password , som tar en SecureString. På så sätt kan du använda den icke-interaktivt:

$certFile = '\\server\share\pwd-protected.pfx'
$certPass = Read-Host -AsSecureString -Prompt 'Enter the password for certificate: '

$certThumbPrint = (Get-PfxCertificate -FilePath $certFile -Password $certPass ).ThumbPrint

Borttagning av more funktionen

Tidigare levererade PowerShell en funktion i Windows som heter more den omslutna more.com. Funktionen har nu tagits bort.

help Dessutom har funktionen ändrats så att den används more.com i Windows eller systemets standardsökare som anges av $env:PAGER på plattformar som inte är Windows.

cd DriveName: returnerar nu användare till den aktuella arbetskatalogen på den enheten

Tidigare skickade Set-Location eller cd för att återgå till en PSDrive användare till standardplatsen för enheten. Användarna skickas nu till den senast kända aktuella arbetskatalogen för den sessionen.

cd - återgår till föregående katalog

C:\Windows\System32> cd C:\
C:\> cd -
C:\Windows\System32>

Eller i Linux:

PS /etc> cd /usr/bin
PS /usr/bin> cd -
PS /etc>

cd cd -- Och ändra till $HOME.

Update-Help som icke-administratör

Efter populär efterfrågan Update-Help behöver du inte längre köras som administratör. Update-Help sparar nu som standard hjälp till en mapp med användaromfattning.

Where-Object -Not

Med tillägget av -Not parametern till Where-Objectkan filtrera ett objekt i pipelinen för att en egenskap inte finns eller ett null-/tomt egenskapsvärde.

Det här kommandot returnerar till exempel alla tjänster som inte har några definierade beroende tjänster:

Get-Service | Where-Object -Not DependentServices

Ändringar i webb-cmdletar

Det underliggande .NET-API:et för webb-cmdletarna har ändrats till System.Net.Http.HttpClient. Den här ändringen ger många fördelar. Den här ändringen tillsammans med bristande samverkan med Internet Explorer har dock resulterat i flera icke-bakåtkompatibla ändringar i Invoke-WebRequest och Invoke-RestMethod.

  • Invoke-WebRequest stöder nu endast grundläggande HTML-parsning. Invoke-WebRequest returnerar alltid ett BasicHtmlWebResponseObject objekt. Egenskaperna ParsedHtml och Forms har tagits bort.
  • BasicHtmlWebResponseObject.Headers värden är nu String[] i stället Stringför .
  • BasicHtmlWebResponseObject.BaseResponse är nu ett System.Net.Http.HttpResponseMessage objekt.
  • Egenskapen Response för web-cmdlet-undantag är nu ett System.Net.Http.HttpResponseMessage objekt.
  • Strikt RFC-rubrikparsning är nu standard för parametern -Headers och -UserAgent . Detta kan kringgås med -SkipHeaderValidation.
  • file:// och ftp:// URI-scheman stöds inte längre.
  • System.Net.ServicePointManager inställningarna respekteras inte längre.
  • Det finns för närvarande ingen certifikatbaserad autentisering tillgänglig på macOS.
  • Användning av -Credential via en http:// URI resulterar i ett fel. Använd en https:// URI eller ange parametern -AllowUnencryptedAuthentication för att förhindra felet.
  • -MaximumRedirection skapar nu ett avslutande fel när omdirigeringsförsök överskrider den angivna gränsen i stället för att returnera resultatet av den senaste omdirigeringen.
  • I PowerShell 6.2 gjordes en ändring som standard till UTF-8-kodning för JSON-svar. När en teckenuppsättning inte anges för ett JSON-svar ska standardkodningen vara UTF-8 per RFC 8259.
  • Standardkodning inställd på UTF-8 för application-json svar
  • Parametern har lagts -SkipHeaderValidation till för att tillåta Content-Type rubriker som inte är standardkompatibla
  • Parametern har lagts -Form till för att stödja förenklat multipart/form-data stöd
  • Kompatibel, skiftlägeskänslig hantering av relationsnycklar
  • Parametern för webb-cmdletar har lagts till -Resume

Invoke-RestMethod returnerar användbar information när inga data returneras

När ett API bara nullInvoke-RestMethod returnerar serialiserades detta som strängen "null" i stället $nullför . Den här ändringen åtgärdar logiken i Invoke-RestMethod för att korrekt serialisera ett giltigt JSON-literalvärde null som $null.

Webb-cmdletar varnar när -Credential skickas över okrypterade anslutningar

När du använder HTTP skickas innehåll inklusive lösenord som klartext. Den här ändringen är att inte tillåta detta som standard och returnera ett fel om autentiseringsuppgifter skickas osäkert. Användare kan kringgå detta med hjälp av växeln -AllowUnencryptedAuthentication .

Gör -OutFile så att parametern i webb-cmdletar fungerar som -LiteralPath

Från och med PowerShell 7.1 fungerar OutFile-parametern för webb-cmdletarna som LiteralPath och bearbetar inte jokertecken.

API-ändringar

Ta bort AddTypeCommandBase klass

Klassen AddTypeCommandBase togs bort från Add-Type för att förbättra prestandan. Den här klassen används endast av cmdleten Add-Type och bör inte påverka användarna.

Har tagits bort VisualBasic som ett språk som stöds i Add-Type

Tidigare kunde du kompilera Visual Basic-kod med hjälp av cmdleten Add-Type . Visual Basic användes sällan med Add-Type. Vi har tagit bort den här funktionen för att minska storleken på PowerShell.

Stöd har tagits bort RunspaceConfiguration

När du tidigare skapade ett PowerShell-körningsutrymme programmatiskt med hjälp av API:et kunde du använda de äldre RunspaceConfiguration eller nyare InitialSessionState klasserna. Den här ändringen tog bort stöd för RunspaceConfiguration och stöder InitialSessionStateendast .

CommandInvocationIntrinsics.InvokeScriptbinda argument till i stället för $input$args

En felaktig position för en parameter resulterade i att args skickades som indata i stället för som args.

Ta bort ClrVersion och BuildVersion egenskaper från $PSVersionTable

Egenskapen ClrVersion $PSVersionTable för är inte användbar med CoreCLR. Slutanvändarna bör inte använda det värdet för att fastställa kompatibiliteten.

Egenskapen BuildVersion var kopplad till Windows-versionsversionen, som inte är tillgänglig på plattformar som inte är Windows-plattformar. Använd egenskapen GitCommitId för att hämta den exakta versionen av PowerShell.

Implementera Unicode escape-parsning

`u#### eller `u{####} konverteras till motsvarande Unicode-tecken. Om du vill mata ut en literal `uundfly du backticken: ``u.

Problem med parameterbindning i ValueFromRemainingArguments PS-funktioner

ValueFromRemainingArguments returnerar nu värdena som en matris i stället för ett enda värde som i sig är en matris.

Rensat användning av CommandTypes.Workflow och WorkflowInfoCleaned

Rensa kod som är relaterad till användning av CommandTypes.Workflow och WorkflowInfo i System.Management.Automation.

Dessa mindre icke-bakåtkompatibla ändringar påverkar främst hjälpproviderns kod.

  • Ändra de offentliga konstruktorerna WorkflowInfo till interna. Vi stöder inte arbetsflöde längre, så det är vettigt att inte tillåta att personer skapar Workflow instanser.
  • Ta bort typen System.Management.Automation.DebugSource eftersom den endast används för arbetsflödesfelsökning.
  • Ta bort överlagringen av SetParent från den abstrakta klassen Felsökningsprogram som endast används för arbetsflödesfelsökning.
  • Ta bort samma överlagring av SetParent från den härledda klassen RemotingJobDebugger.

Omslut inte returresultatet PSObject när du konverterar en ScriptBlock till ett ombud

När en ScriptBlock konverteras till en ombudstyp som ska användas i C#-kontext, medför omslutning av resultatet i en PSObject onödiga problem:

  • När värdet konverteras till ombudets returtyp, packas i princip upp PSObject . PSObject Så är onödig.
  • När ombudets returtyp är object, omsluts den i en PSObject vilket gör det svårt att arbeta med i C#-kod.

Efter den här ändringen är det returnerade objektet det underliggande objektet.

Stöd för fjärrkommunikation

PowerShell-fjärrkommunikation (PSRP) med WinRM på Unix-plattformar kräver NTLM/Negotiate eller Basic Auth via HTTPS. PSRP på macOS stöder endast Grundläggande autentisering via HTTPS. Kerberos-baserad autentisering stöds inte för plattformar som inte är Windows-plattformar.

PowerShell stöder även PowerShell-fjärrkommunikation (PSRP) via SSH på alla plattformar (Windows, macOS och Linux). Mer information finns i SSH-fjärrkommunikation i PowerShell.

PowerShell Direct för containrar försöker använda pwsh först

PowerShell Direct är en funktion i PowerShell och Hyper-V som gör att du kan ansluta till en virtuell Hyper-V-dator eller container utan nätverksanslutning eller andra fjärrhanteringstjänster.

Tidigare anslöt PowerShell Direct med den inbyggda Windows PowerShell-instansen i containern. Nu försöker PowerShell Direct först ansluta med hjälp av alla tillgängliga pwsh.exe i PATH miljövariabeln. Om pwsh.exe inte är tillgängligt återgår PowerShell Direct till att använda powershell.exe.

Enable-PSRemoting skapar nu separata fjärrkommunikationsslutpunkter för förhandsversioner

Enable-PSRemoting skapar nu två konfigurationer för fjärrkommunikationssessioner:

  • En för huvudversionen av PowerShell. Exempel: PowerShell.6 Den här slutpunkten som kan användas i delversionsuppdateringar som "systemomfattande" PowerShell 6-sessionskonfiguration
  • En versionsspecifik sessionskonfiguration, till exempel: PowerShell.6.1.0

Det här beteendet är användbart om du vill ha flera PowerShell 6-versioner installerade och tillgängliga på samma dator.

Dessutom får förhandsversioner av PowerShell nu egna konfigurationer för fjärrkommunikationssessioner när cmdleten Enable-PSRemoting har körts:

C:\WINDOWS\system32> Enable-PSRemoting

Dina utdata kan skilja sig om du inte har konfigurerat WinRM tidigare.

WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.

Sedan kan du se separata PowerShell-sessionskonfigurationer för förhandsversionen och stabila versioner av PowerShell 6 och för varje specifik version.

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

user@host:port syntax som stöds för SSH

SSH-klienter stöder vanligtvis en anslutningssträng i formatet user@host:port. Med tillägg av SSH som ett protokoll för PowerShell-fjärrkommunikation har vi lagt till stöd för det här formatet för anslutningssträng:

Enter-PSSession -HostName fooUser@ssh.contoso.com:2222

Telemetri kan bara inaktiveras med en miljövariabel

PowerShell skickar grundläggande telemetridata till Microsoft när den startas. Data innehåller os-namn, os-version och PowerShell-version. Med dessa data kan vi bättre förstå de miljöer där PowerShell används och göra det möjligt för oss att prioritera nya funktioner och korrigeringar.

Om du vill välja bort den här telemetrin anger du miljövariabeln POWERSHELL_TELEMETRY_OPTOUT till true, yeseller 1. Vi stöder inte längre borttagning av filen DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY för att inaktivera telemetri.