Présentation d’un module Windows PowerShell

Un module est un ensemble de fonctionnalités Windows PowerShell associées, regroupées sous la forme d’une unité pratique (généralement enregistrées dans un seul répertoire). En définissant un ensemble de fichiers de script, d’assemblys et de ressources associées en tant que module, vous pouvez référencer, charger, conserver et partager votre code beaucoup plus facilement que vous le feriez autrement.

L’objectif principal d’un module est de permettre la modularisation (c’est-à-dire, réutilisation et abstraction) du code Windows PowerShell. Par exemple, la façon la plus simple de créer un module consiste à enregistrer simplement un script Windows PowerShell en tant que fichier .psm1. Cela vous permet de contrôler (par exemple, rendre publiques ou privées) les fonctions et variables contenues dans le script. L’enregistrement du script en tant que fichier .psm1 vous permet également de contrôler l’étendue de certaines variables. Enfin, vous pouvez également utiliser des applets de commande telles que 'installation-module pour organiser, installer et utiliser votre script comme blocs de construction pour des solutions plus volumineuses.

Composants et types de module

Un module est constitué de quatre composants de base :

1. Un fichier de code - généralement un script PowerShell ou un assembly d’applet de commande managé.

2. Tout autre élément dont le fichier de code ci-dessus peut avoir besoin, comme des assemblys supplémentaires, des fichiers d’aide ou des scripts.

3. Fichier manifeste qui décrit les fichiers ci-dessus, ainsi que stocke les métadonnées telles que les informations de création et de contrôle de version.

4. Répertoire qui contient tout le contenu ci-dessus et se trouve où PowerShell peut raisonnablement le trouver.

   Remarque

   Aucun de ces composants, par eux-mêmes, n’est réellement nécessaire. Par exemple, un module ne peut être techniquement qu’un script stocké dans un fichier .psm1. Vous pouvez également disposer d’un module qui n’est rien d’autre qu’un fichier manifeste, qui est principalement utilisé à des fins organisationnelles. Vous pouvez également écrire un script qui crée dynamiquement un module et, par conséquent, n’a pas besoin d’un répertoire pour stocker quoi que ce soit. Les sections suivantes décrivent les types de modules que vous pouvez obtenir en mélangeant et en correspondant les différentes parties possibles d’un module ensemble.

Script Modules

Comme le nom l’indique, un module de script est un fichier (.psm1) qui contient n’importe quel code Windows PowerShell valide. Les développeurs de scripts et les administrateurs peuvent utiliser ce type de module pour créer des modules dont les membres incluent des fonctions, des variables, etc. Au cœur, un module de script est simplement un script Windows PowerShell avec une autre extension, ce qui permet aux administrateurs d’utiliser des fonctions d’importation, d’exportation et de gestion sur celle-ci.

En outre, vous pouvez utiliser un fichier manifeste pour inclure d’autres ressources dans votre module, telles que des fichiers de données, d’autres modules dépendants ou des scripts d’exécution. Les fichiers manifestes sont également utiles pour le suivi des métadonnées telles que la création et les informations de contrôle de version.

Enfin, un module de script, comme tout autre module qui n’est pas créé dynamiquement, doit être enregistré dans un dossier que PowerShell peut raisonnablement découvrir. En règle générale, il s’agit du chemin du module PowerShell ; mais si nécessaire, vous pouvez décrire explicitement l’emplacement d’installation de votre module. Pour plus d’informations, consultez Comment écrire un module de script PowerShell.

Modules binaires

Un module binaire est un assembly .NET Framework (.dll) qui contient du code compilé, tel que C#. Les développeurs d’applets de commande peuvent utiliser ce type de module pour partager des applets de commande, des fournisseurs, etc. (Les composants logiciels enfichables existants peuvent également être utilisés en tant que modules binaires.) Par rapport à un module de script, un module binaire vous permet de créer des applets de commande qui sont plus rapides ou utilisent des fonctionnalités (telles que le multithreading) qui ne sont pas aussi faciles à coder dans les scripts Windows PowerShell.

Comme pour les modules de script, vous pouvez inclure un fichier manifeste pour décrire des ressources supplémentaires utilisées par votre module et suivre les métadonnées relatives à votre module. De même, vous devez probablement installer votre module binaire dans un dossier quelque part le long du chemin du module PowerShell. Pour plus d’informations, consultez Comment Comment écrire un module binaire PowerShell.

Modules manifestes

Un module manifeste est un module qui utilise un fichier manifeste pour décrire tous ses composants, mais qui n’a pas de type d’assembly ou de script principal. (Formellement, un module manifeste laisse l’élément ModuleToProcess ou RootModule du manifeste vide.) Toutefois, vous pouvez toujours utiliser les autres fonctionnalités d’un module, telles que la possibilité de charger des assemblys dépendants ou d’exécuter automatiquement certains scripts de prétraitement. Vous pouvez également utiliser un module manifeste comme moyen pratique de empaqueter des ressources que d’autres modules utiliseront, telles que des modules imbriqués, des assemblys, des types ou des formats. Pour plus d’informations, consultez Comment écrire un manifeste de module PowerShell.

Modules dynamiques

Un module dynamique est un module qui n’est pas chargé ou enregistré dans un fichier. Au lieu de cela, ils sont créés dynamiquement par un script, à l’aide de l’applet de commande New-Module. Ce type de module permet à un script de créer un module à la demande qui n’a pas besoin d’être chargé ou enregistré dans un stockage persistant. Par sa nature, un module dynamique est destiné à être de courte durée et ne peut donc pas être accessible par l’applet de commande Get-Module. De même, ils n’ont généralement pas besoin de manifestes de module, ni de dossiers permanents pour stocker leurs assemblys associés.

Manifestes de module

Un manifeste de module est un fichier .psd1 qui contient une table de hachage. Les clés et les valeurs de la table de hachage effectuent les opérations suivantes :

• Décrire le contenu et les attributs du module.

• Définissez les prérequis.

• Déterminez la façon dont les composants sont traités.

  Les manifestes ne sont pas requis pour un module. Les modules peuvent référencer des fichiers de script (.ps1), des fichiers de module de script (.psm1), des fichiers manifestes (.psd1), des fichiers de mise en forme et des fichiers de type (.ps1xml), des assemblys d’applet de commande et des assemblys de fournisseur (.dll), des fichiers d’aide, des fichiers d’aide, des fichiers de localisation ou tout autre type de fichier ou de ressource inclus dans le module. Pour un script internationalisé, le dossier du module contient également un ensemble de fichiers de catalogue de messages. Si vous ajoutez un fichier manifeste au dossier du module, vous pouvez référencer les plusieurs fichiers en tant qu’unité unique en référençant le manifeste.

  Le manifeste lui-même décrit les catégories d’informations suivantes :

• Métadonnées relatives au module, telles que le numéro de version du module, l’auteur et la description.

• Conditions préalables requises pour importer le module, comme la version de Windows PowerShell, la version clR (Common Language Runtime) et les modules requis.

• Les directives de traitement, telles que les scripts, les formats et les types à traiter.

• Restrictions sur les membres du module à exporter, telles que les alias, les fonctions, les variables et les applets de commande à exporter.

  Pour plus d’informations, consultez Comment écrire un manifeste de module PowerShell.

Stockage et installation d’un module

Une fois que vous avez créé un script, un fichier binaire ou un module manifeste, vous pouvez enregistrer votre travail dans un emplacement auquel d’autres utilisateurs peuvent y accéder. Par exemple, votre module peut être stocké dans le dossier système où Windows PowerShell est installé, ou il peut être stocké dans un dossier utilisateur.

En règle générale, vous pouvez déterminer où vous devez installer votre module à l’aide de l’un des chemins stockés dans la variable $Env:PSModulePath. L’utilisation de l’un de ces chemins signifie que PowerShell peut rechercher et charger automatiquement votre module lorsqu’un utilisateur effectue un appel à celui-ci dans son code. Si vous stockez votre module ailleurs, vous pouvez indiquer explicitement à PowerShell en passant l’emplacement de votre module en tant que paramètre lorsque vous appelez Install-Module.

Quel que soit le chemin d’accès du dossier, appelé base du module (ModuleBase), et le nom du script, du fichier binaire ou du module manifeste doit être identique au nom du dossier du module, à l’exception suivante :

• Les modules dynamiques créés par l’applet de commande New-Module peuvent être nommés à l’aide du paramètre Name de l’applet de commande.

• Les modules importés à partir d’objets d’assembly par la commande Import-Module -Assembly sont nommés en fonction de la syntaxe suivante : "dynamic_code_module_" + assembly.GetName().

  Pour plus d’informations, consultez Installation d’un module PowerShell et about_PSModulePath.

Applets de commande et variables de module

Les applets de commande et variables suivantes sont fournies par Windows PowerShell pour la création et la gestion des modules.

applet de commande New-Module Cette applet de commande crée un module dynamique qui existe uniquement en mémoire. Le module est créé à partir d’un bloc de script et ses membres exportés, tels que ses fonctions et variables, sont immédiatement disponibles dans la session et restent disponibles jusqu’à ce que la session soit fermée.

applet de commande New-ModuleManifest Cette applet de commande crée un fichier manifeste de module (.psd1), remplit ses valeurs et enregistre le fichier manifeste dans le chemin spécifié. Cette applet de commande peut également être utilisée pour créer un modèle de manifeste de module qui peut être renseigné manuellement.

applet de commande Import-Module Cette applet de commande ajoute un ou plusieurs modules à la session active.

applet de commande Get-Module Cette applet de commande récupère des informations sur les modules qui ont été ou qui peuvent être importés dans la session active.

'applet de commande Export-ModuleMember Cette applet de commande spécifie les membres du module (tels que les applets de commande, les fonctions, les variables et les alias) exportés à partir d’un fichier de module de script (.psm1) ou d’un module dynamique créé à l’aide de l’applet de commande New-Module.

applet de commande Remove-Module Cette applet de commande supprime les modules de la session active.

applet de commande Test-ModuleManifest Cette applet de commande vérifie qu’un module décrit avec précision les composants d’un module en vérifiant que les fichiers répertoriés dans le fichier manifeste du module (.psd1) existent réellement dans les chemins spécifiés.

$PSScriptRoot Cette variable contient le répertoire à partir duquel le module de script est exécuté. Il permet aux scripts d’utiliser le chemin du module pour accéder à d’autres ressources.

$Env :PSModulePath Cette variable d’environnement contient une liste des répertoires dans lesquels les modules Windows PowerShell sont stockés. Windows PowerShell utilise la valeur de cette variable lors de l’importation automatique des modules et de la mise à jour des rubriques d’aide pour les modules.

Voir aussi

écrire un de module Windows PowerShell