about_PowerShell_Editions
Descrizione breve
Diverse edizioni di PowerShell vengono eseguite in runtime sottostanti diversi.
Descrizione lunga
Da PowerShell 5.1 sono disponibili più edizioni di PowerShell eseguite in un runtime .NET diverso. A partire da PowerShell 6.0 sono disponibili due edizioni di PowerShell:
- Desktop, che viene eseguito in .NET Framework. PowerShell 4 e versioni successive, oltre a PowerShell 5.1 sono disponibili per edizioni di Windows complete come Desktop di Windows, Windows Server, Windows Server Core e la maggior parte degli altri sistemi operativi Windows. Questa è l'edizione originale di PowerShell ed è inclusa nell'installazione predefinita del sistema operativo.
- Core, che viene eseguito in .NET Core. PowerShell 6.0 e versioni successive è installato side-by-side con le versioni precedenti di PowerShell nelle edizioni di Windows complete, alcune edizioni di Windows con footprint ridotto, ad esempio Windows Nano Server e Windows IoT, o su piattaforme non Windows come Linux e macOS.
Poiché l'edizione di PowerShell corrisponde al runtime .NET, è l'indicatore principale della compatibilità dell'API .NET e del modulo PowerShell; alcune API .NET, tipi o metodi non sono disponibili sia in runtime .NET che influiscono su script e moduli di PowerShell che dipendono da essi.
Variabile $PSEdition
automatica
In PowerShell 5.1 e versioni successive è possibile scoprire l'edizione in esecuzione con la $PSEdition
variabile automatica:
$PSEdition
Core
In PowerShell 4 e versioni successive questa variabile non esiste. $PSEdition
essere Null deve essere considerato come uguale a quello del valore Desktop
.
Edizione in $PSVersionTable
La $PSVersionTable
variabile automatica ha anche la proprietà PSEdition in PowerShell 5.1 e versioni successive:
$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
Il campo PSEdition ha lo stesso valore della $PSEdition
variabile automatica.
Campo manifesto del CompatiblePSEditions
modulo
I moduli di PowerShell possono dichiarare le edizioni di PowerShell compatibili con l'uso del CompatiblePSEditions
campo del manifesto del modulo.
Ad esempio, un manifesto del modulo che dichiara la compatibilità con entrambe Desktop
le edizioni di Core
PowerShell:
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop', 'Core')
}
Esempio di manifesto di un modulo con solo Desktop
compatibilità:
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop')
}
L'omissione del CompatiblePSEditions
campo da un manifesto del modulo avrà lo stesso effetto dell'impostazione su Desktop
, poiché i moduli creati prima dell'introduzione di questo campo sono stati scritti in modo implicito per questa edizione.
Per i moduli non forniti come parte di Windows (ovvero i moduli scritti o installati dalla raccolta), questo campo è solo informativo; PowerShell non modifica il comportamento in base al CompatiblePSEditions
campo, ma lo espone sull'oggetto PSModuleInfo
(restituito da Get-Module
) per la propria logica:
New-ModuleManifest -Path .\TestModuleWithEdition.psd1 -CompatiblePSEditions Desktop,Core -PowerShellVersion '5.1'
$ModuleInfo = Test-ModuleManifest -Path .\TestModuleWithEdition.psd1
$ModuleInfo.CompatiblePSEditions
Desktop
Core
Nota
Il campo modulo CompatiblePSEditions
è compatibile solo con PowerShell 5.1 e versioni successive. L'inclusione di questo campo causerà l'incompatibilità di un modulo con PowerShell 4 e versioni successive. Poiché il campo è puramente informativo, può essere omesso in modo sicuro nelle versioni successive di PowerShell.
In PowerShell 6.1 il Get-Module -ListAvailable
formattatore è stato aggiornato per visualizzare la compatibilità dell'edizione di ogni modulo:
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...
Compatibilità dell'edizione per i moduli forniti come parte di Windows
Per i moduli inclusi in Windows (o installati come parte di un ruolo o di una funzionalità), PowerShell 6.1 e versioni successive considerano il CompatiblePSEditions
campo in modo diverso. Tali moduli sono disponibili nella directory dei moduli di sistema di Windows PowerShell (%windir%\System\WindowsPowerShell\v1.0\Modules
).
Per i moduli caricati o trovati in questa directory, PowerShell 6.1 e versioni successive usa il CompatiblePSEditions
campo per determinare se il modulo sarà compatibile con la sessione corrente e si comporta di conseguenza.
Quando Import-Module
viene usato, un modulo senza Core
in CompatiblePSEditions
non verrà importato e verrà visualizzato un errore:
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
Quando Get-Module -ListAvailable
viene usato, i moduli senza Core
in CompatiblePSEditions
non verranno visualizzati:
Get-Module -ListAvailable BitsTransfer
# No output
In entrambi i casi, il parametro switch può essere usato per eseguire l'override -SkipEditionCheck
di questo comportamento:
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,...
Avviso
Import-Module -SkipEditionCheck
potrebbe sembrare che abbia esito positivo per un modulo, ma l'uso di tale modulo comporta il rischio di incompatibilità in un secondo momento; durante il caricamento iniziale del modulo ha esito positivo, un comando può in seguito chiamare un'API incompatibile e non riuscire spontaneamente.
Creazione di moduli di PowerShell per la compatibilità tra le edizioni
Quando si scrive un modulo di PowerShell per le Desktop
edizioni e Core
di PowerShell, è possibile eseguire operazioni per garantire la compatibilità tra edizioni.
L'unico modo vero per confermare e convalidare continuamente la compatibilità consiste tuttavia nel scrivere test per lo script o il modulo ed eseguirli in tutte le versioni e edizioni di PowerShell con cui è necessaria la compatibilità. Un framework di test consigliato per questo è Pester.
Script di PowerShell
Come linguaggio, PowerShell funziona allo stesso modo tra le edizioni; si tratta dei cmdlet, dei moduli e delle API .NET usati che sono interessati dalla compatibilità dell'edizione.
In genere, gli script che funzionano in PowerShell 6.1 e versioni successive funzioneranno con Windows PowerShell 5.1, ma esistono alcune eccezioni.
PSScriptAnalyzer versione 1.18+ include regole come PSUseCompatibleCommands e PSUseCompatibleTypes che sono in grado di rilevare un utilizzo potenzialmente incompatibile di comandi e API .NET negli script di PowerShell.
Assembly .NET
Se si scrive un modulo binario o un modulo che incorpora gli assembly .NET (DLL) generati dal codice sorgente, è necessario eseguire la compilazione in base a .NET Standard e PowerShell Standard per la convalida della compatibilità in fase di compilazione di .NET e della compatibilità delle API di PowerShell.
Anche se queste librerie sono in grado di verificare la compatibilità in fase di compilazione, non saranno in grado di intercettare le possibili differenze comportamentali tra le edizioni. Per questo motivo è comunque necessario scrivere test.