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, plusieurs éditions de PowerShell sont exécutées sur un runtime .NET différent. À partir de PowerShell 6.2, il existe deux éditions de PowerShell :
- Bureau, qui s’exécute sur .NET Framework. PowerShell 4 et ci-dessous, ainsi que PowerShell 5.1 sur des éditions Windows complètes comme Windows Desktop, Windows Server, Windows Server Core et la plupart des autres systèmes d’exploitation Windows sont édition 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 à empreinte réduite, 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 de l’indicateur principal de la 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 et cela affecte les scripts et modules PowerShell qui dépendent de ces derniers.
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 ci-dessous, cette variable n’existe pas. $PSEdition étant null doit être traité comme étant identique à avoir 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 compatibles avec le CompatiblePSEditions champ du manifeste de module.
Par exemple, un manifeste de module déclarant la compatibilité avec les deux Desktop éditions de Core PowerShell :
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop', 'Core')
}
Exemple de manifeste de module avec uniquement Desktop la compatibilité :
@{
ModuleVersion = '1.0'
FunctionsToExport = @('Test-MyModule')
CompatiblePSEditions = @('Desktop')
}
L’omission du CompatiblePSEditions champ à partir d’un manifeste de module aura le même effet que la définition Desktopde ce champ, car les modules créés avant l’introduction de ce champ ont été implicitement écrits pour cette édition.
Pour les modules non livrés dans le cadre de Windows (c’est-à-dire les modules que vous écrivez ou installez à partir de la galerie), ce champ est informationnel uniquement ; PowerShell ne change 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 ci-dessous.
Étant donné que le champ est purement informationnel, 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é de l’é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é de l’édition pour les modules qui sont fournis dans le cadre de Windows
Pour les modules qui font partie de Windows (ou 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 sont trouvés dans le répertoire des modules système Windows PowerShell (%windir%\System\WindowsPowerShell\v1.0\Modules).
Pour les modules chargés à partir ou trouvés dans ce répertoire, PowerShell 6.1 et versions ultérieures utilise le CompatiblePSEditions champ pour déterminer si le module sera compatible avec la session active et se comporte en conséquence.
Lorsqu’il Import-Module est utilisé, un module sans Core entrée 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 il est utilisé, les modules sans Core entrée CompatiblePSEditions ne s’affichent pas :
Get-Module -ListAvailable BitsTransfer
# No output
Dans les deux cas, le -SkipEditionCheck paramètre de commutateur 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 exécute le risque de rencontrer une incompatibilité ultérieurement; lors du chargement du module réussit initialement, une commande peut ensuite appeler une API incompatible et échouer spontanément.
Création de modules PowerShell pour la compatibilité croisée de l’édition
Lors de l’écriture d’un module PowerShell pour cibler à la fois Desktop et Core les éditions de PowerShell, vous pouvez effectuer des opérations pour garantir la compatibilité entre éditions.
La seule façon vraie 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 ; il s’agit des applets de commande, des modules et des API .NET que vous utilisez qui sont affectées par la compatibilité de l’édition.
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 certaines exceptions.
PSScriptAnalyzer version 1.18+ a des règles telles que PSUseCompatibleCommands et PSUseCompatibleTypes qui sont en mesure de détecter l’utilisation éventuellement 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 compiler sur .NET Standard et PowerShell Standard pour la validation de compatibilité au moment de la compilation de la compatibilité .NET et de la compatibilité de l’API PowerShell.
Bien que ces bibliothèques puissent vérifier une certaine compatibilité au moment de la compilation, elles ne pourront pas intercepter les différences de comportement possibles entre les éditions. Pour cela, vous devez toujours écrire des tests.