Om PowerShell-utgåvor
Kort beskrivning
Olika utgåvor av PowerShell körs på olika underliggande körningsmiljöer.
Lång beskrivning
Från PowerShell 5.1 finns det flera utgåvor av PowerShell som var och en körs på en annan .NET-körning. Från och med PowerShell 6.2 finns det två utgåvor av PowerShell:
- Desktop, som körs på .NET Framework. PowerShell 4 och nedan, samt PowerShell 5.1 på fullständiga Windows-utgåvor som Windows Desktop, Windows Server, Windows Server Core och de flesta andra Windows-operativsystem är Desktop Edition. Det här är den ursprungliga PowerShell-utgåvan.
- Core, som körs på .NET Core. PowerShell 6.0 och senare, samt PowerShell 5.1 på vissa Windows-versioner med reducerat fotavtryck, till exempel Windows Nano Server och Windows IoT där .NET Framework inte är tillgänglig.
Eftersom utgåvan av PowerShell motsvarar dess .NET-körning är den den primära indikatorn för .NET API och PowerShell-modulkompatibilitet. vissa .NET-API:er, typer eller metoder är inte tillgängliga i både .NET-runtimes och detta påverkar PowerShell-skript och moduler som är beroende av dem.
Den $PSEdition automatiska variabeln
I PowerShell 5.1 och senare kan du ta reda på vilken utgåva du kör med den $PSEdition automatiska variabeln:
$PSEdition
Core
I PowerShell 4 och nedan finns inte den här variabeln. $PSEdition vara null ska behandlas som samma som att ha värdet Desktop.
Utgåva i $PSVersionTable
Den $PSVersionTable automatiska variabeln har även versionsinformation i PowerShell 5.1 och senare:
$PSVersionTable
Name Value
---- -----
PSVersion 6.2.0-rc.1
PSEdition Core # <-- Edition information
GitCommitId 6.2.0-rc.1
OS Microsoft Windows 10.0.18865
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Fältet PSEdition har samma värde som den $PSEdition automatiska variabeln.
Modulmanifestfältet CompatiblePSEditions
PowerShell-moduler kan deklarera vilka utgåvor av PowerShell de är kompatibla med med hjälp CompatiblePSEditions av fältet i modulmanifestet.
Till exempel ett modulmanifest som deklarerar kompatibilitet med både Desktop och Core utgåvor av PowerShell:
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop', 'Core')
}
Ett exempel på ett modulmanifest med endast Desktop kompatibilitet:
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop')
}
Om du utelämnar CompatiblePSEditions fältet från ett modulmanifest har det samma effekt som att ställa in det på Desktop, eftersom moduler som skapades innan det här fältet introducerades skrevs implicit för den här utgåvan.
För moduler som inte levereras som en del av Windows (dvs. moduler som du skriver eller installerar från galleriet) är det här fältet endast informationsspecifikt. PowerShell ändrar inte beteendet baserat på CompatiblePSEditions fältet, men exponerar det på PSModuleInfo objektet (returneras av Get-Module) för din egen logik:
New-ModuleManifest -Path .\TestModuleWithEdition.psd1 -CompatiblePSEditions Desktop,Core -PowerShellVersion '5.1'
$ModuleInfo = Test-ModuleManifest -Path .\TestModuleWithEdition.psd1
$ModuleInfo.CompatiblePSEditions
Desktop
Core
Anteckning
Modulfältet CompatiblePSEditions är endast kompatibelt med PowerShell 5.1 och senare. Om du inkluderar det här fältet blir en modul inkompatibel med PowerShell 4 och nedan. Eftersom fältet är rent informationsfritt kan det utelämnas i senare PowerShell-versioner.
I PowerShell 6.1 Get-Module -ListAvailable har formateraren uppdaterats för att visa kompatibiliteten för varje modul:
Get-Module -ListAvailable
Directory: C:\Users\me\Documents\PowerShell\Modules
ModuleType Version Name PSEdition ExportedCommands
---------- ------- ---- --------- ----------------
Script 1.4.0 Az Core,Desk
Script 1.3.1 Az.Accounts Core,Desk {Disable-AzDataCollection, Disable-AzContextAutosave, E...
Script 1.0.1 Az.Aks Core,Desk {Get-AzAks, New-AzAks, Remove-AzAks, Import-AzAksCreden...
...
Script 4.4.0 Pester Desk {Describe, Context, It, Should...}
Script 1.18.0 PSScriptAnalyzer Desk {Get-ScriptAnalyzerRule, Invoke-ScriptAnalyzer, Invoke-...
Script 1.0.0 WindowsCompatibility Core {Initialize-WinSession, Add-WinFunction, Invoke-WinComm...
Versionskompatibilitet för moduler som levereras som en del av Windows
För moduler som ingår i Windows (eller installeras som en del av en roll eller funktion) behandlar CompatiblePSEditions PowerShell 6.1 och senare fältet annorlunda. Sådana moduler finns i katalogen Windows PowerShell systemmoduler (%windir%\System\WindowsPowerShell\v1.0\Modules).
För moduler som läses in från eller finns i den här katalogen använder CompatiblePSEditions PowerShell 6.1 och senare fältet för att avgöra om modulen kommer att vara kompatibel med den aktuella sessionen och fungerar därefter.
När Import-Module används importeras inte en modul utan Core in CompatiblePSEditions och ett fel visas:
Import-Module BitsTransfer
Import-Module : Module 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\BitsT
ransfer\BitsTransfer.psd1' does not support current PowerShell edition 'Core'.
Its supported editions are 'Desktop'. Use 'Import-Module -SkipEditionCheck' to i
gnore the compatibility of this module.
At line:1 char:1
+ Import-Module BitsTransfer
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (C:\WINDOWS\system32\u2026r\BitsT
ransfer.psd1:String) [Import-Module], InvalidOperationException
+ FullyQualifiedErrorId : Modules_PSEditionNotSupported,Microsoft.PowerShell.Com
mands.ImportModuleCommand
När Get-Module -ListAvailable används visas inte moduler utan Core i CompatiblePSEditions :
Get-Module -ListAvailable BitsTransfer
# No output
I båda fallen -SkipEditionCheck kan växelparametern användas för att åsidosätta det här beteendet:
Get-Module -ListAvailable -SkipEditionCheck BitsTransfer
Directory: C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
ModuleType Version Name PSEdition ExportedCommands
---------- ------- ---- --------- ----------------
Manifest 2.0.0.0 BitsTransfer Desk {Add-BitsFile, Complete-BitsTransfer, Get-BitsTransfer,...
Varning
Import-Module -SkipEditionCheck kan verka vara framgångsrikt för en modul, men om du använder den modulen riskerar du att stöta på en inkompatibilitet senare; medan inläsningen av modulen först lyckas kan ett kommando senare anropa ett inkompatibelt API och misslyckas spontant.
Redigera PowerShell-moduler för kompatibilitet mellan utgåvor
När du skriver en PowerShell-modul för att rikta in dig på både Desktop och Core utgåvor av PowerShell finns det saker du kan göra för att säkerställa kompatibilitet mellan utgåvor.
Det enda sanna sättet att bekräfta och kontinuerligt verifiera kompatibilitet är dock att skriva tester för skriptet eller modulen och köra dem på alla versioner och utgåvor av PowerShell som du behöver kompatibilitet med. Ett rekommenderat testramverk för detta är Pester.
PowerShell-skript
Som språk fungerar PowerShell på samma sätt mellan utgåvorna. det är de cmdletar, moduler och .NET-API:er som du använder som påverkas av versionskompatibiliteten.
I allmänhet fungerar skript som fungerar i PowerShell 6.1 och senare med Windows PowerShell 5.1, men det finns vissa undantag.
PsScriptAnalyzer-modulen version 1.18.0 har regler som PSUseCompatibleCommands och PSUseCompatibleTypes som kan identifiera eventuellt inkompatibel användning av kommandon och .NET-API:er i PowerShell-skript.
.NET-sammansättningar
Om du skriver en binär modul eller en modul som innehåller .NET-sammansättningar (DLL:er) som genererats från källkoden bör du kompilera mot .NET Standard och PowerShell Standard för kompileringstidskompatibilitetsvalidering av .NET- och PowerShell API-kompatibilitet.
Även om de här biblioteken kan kontrollera viss kompatibilitet vid kompileringstillfället kan de inte fånga upp möjliga beteendeskillnader mellan utgåvor. För detta måste du fortfarande skriva tester.