about_PowerShell_Editions

  • Article

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 autre runtime .NET. À partir de PowerShell 6.0, il existe deux éditions de PowerShell :

  • Bureau, qui s’exécute sur .NET Framework. PowerShell 4 et versions ultérieures, ainsi que PowerShell 5.1 sont disponibles pour les éditions Windows complètes telles que Windows Desktop, Windows Server, Windows Server Core et la plupart des autres systèmes d’exploitation Windows. Il s’agit de l’édition PowerShell d’origine et est incluse dans l’installation par défaut du système d’exploitation.
  • Core, qui s’exécute sur .NET Core. PowerShell 6.0 et versions ultérieures est installé côte à côte avec les versions antérieures de PowerShell sur des éditions Windows complètes, certaines éditions Windows à encombrement réduit, telles que Windows Nano Server et Windows IoT, ou sur des plateformes non Windows telles que Linux et macOS.

É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 runtimes .NET et cela affecte les scripts powerShell et les modules 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 être null doit être traité comme identique à avoir la valeur Desktop.

Édition dans $PSVersionTable

La $PSVersionTable variable automatique a également la propriété PSEdition dans PowerShell 5.1 et versions ultérieures :

$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

Le champ PSEdition a la même valeur que la $PSEdition variable automatique.

Champ manifeste du CompatiblePSEditions module

Les modules PowerShell peuvent déclarer les éditions de PowerShell compatibles avec le CompatiblePSEditions champ du manifeste du module.

Par exemple, un manifeste de module déclarant la compatibilité avec les deux Desktop et Core les éditions de 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 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 fournis 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 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

Remarque

Le CompatiblePSEditions champ de module est compatible uniquement 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 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é des éditions 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 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 se trouvent 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 sont pas affichés :

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 ; lorsque le 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 les éditions.

La seule façon de confirmer et de valider continuellement la compatibilité consiste à é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é. Un cadre de test recommandé 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 capables 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 effectuer une compilation sur .NET Standard et PowerShell Standard pour la validation de compatibilité au moment de la compilation de .NET et de la compatibilité 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 intercepter les différences comportementales possibles entre les éditions. Pour cela, vous devez toujours écrire des tests.

Voir aussi