Om PowerShell-utgåvor
Kort beskrivning
Olika utgåvor av PowerShell körs på olika underliggande körningar.
Lång beskrivning
Från PowerShell 5.1 finns det flera utgåvor av PowerShell som var och en körs på olika .NET-körningsmiljöer. Från och med PowerShell 6.2 finns det två utgåvor av PowerShell:
- Desktop, som körs på .NET Framework. PowerShell 4 och lägre, 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 begränsade Windows-utgåvor som Windows Nano Server och Windows IoT där .NET Framework inte är tillgängligt.
Eftersom versionen 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åda .NET-körningsmiljöerna 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
att vara null ska behandlas på samma sätt som att ha värdet Desktop
.
Utgåva i $PSVersionTable
Den $PSVersionTable
automatiska variabeln har även utgåvasinformation 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 av fältet i CompatiblePSEditions
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 fältet CompatiblePSEditions
från ett modulmanifest får det samma effekt som att ange det till 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 lägre. 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...
Utgåva-kompatibilitet 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 på olika sätt. 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
i 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 lyckas 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 utgåva av korskompatibilitet
När du skriver en PowerShell-modul för att rikta in dig på både Desktop
och Core
versioner 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 kompatibiliteten med utgåvan.
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 dessa bibliotek 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.