about_PowerShell_Editions
Description courte
Différentes éditions de PowerShell s’exécutent sur différents runtimes sous-jacents.
Description longue
À partir de PowerShell 5.1, il existe plusieurs éditions de PowerShell qui s’exécutent chacune sur un runtime .NET différent. À partir de PowerShell 6.2, il existe deux éditions de PowerShell :
- Desktop, qui s’exécute sur .NET Framework. PowerShell 4 et versions ultérieures, ainsi que PowerShell 5.1 sur les éditions windows complètes telles que Windows Desktop, Windows Server, Windows Server Core et la plupart des autres systèmes d’exploitation Windows sont des éditions Desktop. Il s’agit de l’édition PowerShell d’origine.
- Core, qui s’exécute sur .NET Core. PowerShell 6.0 et versions ultérieures, ainsi que PowerShell 5.1 sur certaines éditions Windows à encombrement réduit, telles que Windows Nano Server et Windows IoT où .NET Framework n’est pas disponible.
Étant donné que l’édition de PowerShell correspond à son runtime .NET, il s’agit du principal indicateur de compatibilité de l’API .NET et du module PowerShell . certaines API,types ou méthodes .NET ne sont pas disponibles dans les deux runtimes .NET, ce qui affecte les scripts et modules PowerShell qui en dépendent.
Variable $PSEdition automatique
Dans PowerShell 5.1 et versions ultérieures, vous pouvez découvrir l’édition que vous exécutez avec la $PSEdition variable automatique :
$PSEdition
Core
Dans PowerShell 4 et versions ultérieures, cette variable n’existe pas. $PSEdition la valeur null doit être traitée comme ayant la valeur Desktop.
Édition dans $PSVersionTable
La $PSVersionTable variable automatique contient également des informations d’édition dans PowerShell 5.1 et versions ultérieures :
$PSVersionTable
Name Value
---- -----
PSVersion 7.1.6
PSEdition Core
GitCommitId 7.1.6
OS Microsoft Windows 10.0.22000
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Le champ PSEdition a la même valeur que la $PSEdition variable automatique.
Champ CompatiblePSEditions manifeste du module
Les modules PowerShell peuvent déclarer les éditions de PowerShell avec lesquelles ils sont compatibles à l’aide du CompatiblePSEditions champ du manifeste du module.
Par exemple, un manifeste de module déclarant la compatibilité avec les Desktop éditions et Core de PowerShell :
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop', 'Core')
}
Exemple de manifeste de module avec compatibilité uniquement Desktop :
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop')
}
Omettre le CompatiblePSEditions champ d’un manifeste de module aura le même effet que de le définir sur Desktop, car les modules créés avant l’introduction de ce champ ont été implicitement écrits pour cette édition.
Pour les modules qui ne font pas partie de Windows (c’est-à-dire les modules que vous écrivez ou installez à partir de la galerie), ce champ est d’information uniquement ; PowerShell ne modifie pas le comportement en fonction du CompatiblePSEditions champ, mais l’expose sur l’objet PSModuleInfo (retourné par Get-Module) pour votre propre logique :
New-ModuleManifest -Path .\TestModuleWithEdition.psd1 -CompatiblePSEditions Desktop,Core -PowerShellVersion '5.1'
$ModuleInfo = Test-ModuleManifest -Path .\TestModuleWithEdition.psd1
$ModuleInfo.CompatiblePSEditions
Desktop
Core
Notes
Le CompatiblePSEditions champ de module est uniquement compatible avec PowerShell 5.1 et versions ultérieures.
L’inclusion de ce champ entraîne l’incompatibilité d’un module avec PowerShell 4 et versions ultérieures.
Étant donné que le champ est purement informatif, il peut être omis en toute sécurité dans les versions ultérieures de PowerShell.
Dans PowerShell 6.1, Get-Module -ListAvailable son formateur a été mis à jour pour afficher la compatibilité d’édition de chaque module :
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é des éditions pour les modules fournis dans le cadre de Windows
Pour les modules qui font partie de Windows (ou qui sont installés dans le cadre d’un rôle ou d’une fonctionnalité), PowerShell 6.1 et versions ultérieures traitent le CompatiblePSEditions champ différemment. Ces modules se trouvent dans le répertoire des modules système Windows PowerShell (%windir%\System\WindowsPowerShell\v1.0\Modules).
Pour les modules chargés à partir de ou trouvés dans ce répertoire, PowerShell 6.1 et versions ultérieures utilise le CompatiblePSEditions champ pour déterminer si le module est compatible avec la session active et se comporte en conséquence.
Quand Import-Module est utilisé, un module sans Core dans CompatiblePSEditions n’est pas importé et une erreur s’affiche :
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
Quand Get-Module -ListAvailable est utilisé, les modules sans Core dans CompatiblePSEditions ne s’affichent pas :
Get-Module -ListAvailable BitsTransfer
# No output
Dans les deux cas, le -SkipEditionCheck paramètre switch peut être utilisé pour remplacer ce comportement :
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,...
Avertissement
Import-Module -SkipEditionCheck peut sembler réussir pour un module, mais l’utilisation de ce module risque de rencontrer une incompatibilité ultérieurement ; Lors du chargement du module, une commande peut appeler ultérieurement une API incompatible et échouer spontanément.
Création de modules PowerShell pour la compatibilité croisée des éditions
Lors de l’écriture d’un module PowerShell pour cibler à la fois les Desktop éditions et Core de PowerShell, vous pouvez effectuer certaines actions pour garantir la compatibilité entre les éditions.
La seule façon réelle de confirmer et de valider continuellement la compatibilité consiste toutefois à écrire des tests pour votre script ou module et à les exécuter sur toutes les versions et éditions de PowerShell avec lesquelles vous avez besoin de compatibilité. Une infrastructure de test recommandée pour cela est Pester.
Script PowerShell
En tant que langage, PowerShell fonctionne de la même façon entre les éditions ; ce sont les applets de commande, les modules et les API .NET que vous utilisez qui sont affectés par la compatibilité des éditions.
En règle générale, les scripts qui fonctionnent dans PowerShell 6.1 et versions ultérieures fonctionnent avec Windows PowerShell 5.1, mais il existe quelques exceptions.
PSScriptAnalyzer version 1.18+ a des règles telles que PSUseCompatibleCommands et PSUseCompatibleTypes qui sont capables de détecter l’utilisation potentiellement incompatible des commandes et des API .NET dans les scripts PowerShell.
assemblys .NET
Si vous écrivez un module binaire ou un module qui incorpore des assemblys .NET (DLL) générés à partir du code source, vous devez effectuer une compilation sur .NET Standard et PowerShell Standard pour la validation de la compatibilité au moment de la compilation de la compatibilité de .NET et de l’API PowerShell.
Bien que ces bibliothèques puissent case activée une certaine compatibilité au moment de la compilation, elles ne pourront pas détecter les différences de comportement possibles entre les éditions. Pour cela, vous devez toujours écrire des tests.