Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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å en annan .NET-körning. Från och med PowerShell 6.0 finns det två utgåvor av PowerShell:
- Desktop, som körs på .NET Framework. PowerShell 4 och lägre, samt PowerShell 5.1 är tillgängliga för fullständiga Windows-utgåvor som Windows Desktop, Windows Server, Windows Server Core och de flesta andra Windows-operativsystem. Detta är den ursprungliga PowerShell-utgåvan och ingår i standardinstallationen av operativsystemet.
- Core, som körs på .NET Core. PowerShell 6.0 och senare installeras sida vid sida med tidigare PowerShell-versioner på fullständiga Windows-utgåvor, vissa Windows-utgåvor med reducerat fotavtryck som Windows Nano Server och Windows IoT eller på plattformar som inte är Windows-plattformar som Linux och macOS.
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-körningar 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 som är null ska behandlas på samma sätt som värdet Desktop.
Utgåva i $PSVersionTable
Den $PSVersionTable automatiska variabeln har även PSEdition-egenskap i PowerShell 5.1 och senare:
$PSVersionTable
Name Value
---- -----
PSVersion 7.3.9
PSEdition Core
GitCommitId 7.3.9
OS Microsoft Windows 10.0.22621
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
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 CompatiblePSEditions 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å Desktopeftersom moduler som skapades innan det här fältet introducerades implicit skrevs 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 informationsligt. PowerShell ändrar inte beteendet baserat på fältet CompatiblePSEditions, men exponerar det på PSModuleInfo -objektet (returneras av Get-Module) för din egen logik:
$newModuleManifestSplat = @{
Path = '.\TestModuleWithEdition.psd1'
CompatiblePSEditions = 'Desktop', 'Core'
PowerShellVersion = '5.1'
}
New-ModuleManifest @newModuleManifestSplat
$ModuleInfo = Test-ModuleManifest -Path .\TestModuleWithEdition.psd1
$ModuleInfo.CompatiblePSEditions
Desktop
Core
Not
Fältet CompatiblePSEditions modul ä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 på ett säkert sätt i senare PowerShell-versioner.
I PowerShell 6.1 har Get-Module -ListAvailable fått sin formaterare uppdaterad 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...
Kompatibilitet med utgåva 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 PowerShell 6.1 och senare CompatiblePSEditions 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 PowerShell 6.1 och senare fältet CompatiblePSEditions för att avgöra om modulen är 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\BitsTransfer\BitsTransfer.psd1'
does not support current PowerShell edition 'Core'. Its supported editions are 'Desktop'. Use 'Import-Module
-SkipEditionCheck' to ignore the compatibility of this module.
At line:1 char:1
+ Import-Module BitsTransfer
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ResourceUnavailable: (C:\WINDOWS\system32\u2026r\BitsTransfer.psd1:String)
[Import-Module], InvalidOperationException
+ FullyQualifiedErrorId : Modules_PSEditionNotSupported,Microsoft.PowerShell.Commands.ImportModuleCommand
När Get-Module -ListAvailable används visas inte moduler utan Core i CompatiblePSEditions:
Get-Module -ListAvailable BitsTransfer
# No output
I båda fallen kan parametern -SkipEditionCheck switch 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 kompatibilitet mellan utgåvor
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åvor. det är de cmdletar, moduler och .NET-API:er som du använder som påverkas av kompatibiliteten i 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 version 1.18+ 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 kompileringskompatibilitetsverifiering 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.