about_Modules
Description courte
Explique comment installer, importer et utiliser des modules PowerShell.
Description longue
PowerShell est à la fois un interpréteur de commandes et un langage de script. Les commandes dans PowerShell sont implémentées en tant que scripts, fonctions ou applets de commande. Le langage inclut des mots clés, qui fournissent la structure et la logique de traitement et d’autres ressources, telles que des variables, des fournisseurs, des alias.
Un module est une unité autonome et réutilisable qui peut inclure des applets de commande, des fournisseurs, des fonctions, des variables et d’autres ressources. Par défaut, PowerShell charge automatiquement un module installé la première fois que vous utilisez une commande à partir du module. Vous pouvez configurer le comportement de chargement automatique du module à l’aide de la variable $PSModuleAutoloadingPreference. Pour plus d’informations, consultez about_Preference_Variables.
Vous pouvez également charger ou décharger manuellement des modules pendant une session PowerShell. Pour charger ou recharger un module, utilisez Import-Module. Pour décharger un module, utilisez l’applet de Remove-Module commande.
PowerShell inclut un ensemble de modules de base. Tout le monde peut créer de nouveaux modules à l’aide de C# ou du langage de script PowerShell lui-même. Les modules écrits en C# en tant qu’assemblys .NET compilés sont appelés modules natifs. Les modules écrits dans PowerShell sont appelés modules de script.
Cet article explique comment utiliser des modules PowerShell. Pour plus d’informations sur la création de modules PowerShell, consultez Écriture d’un module PowerShell.
Remarque
Avant PowerShell 3.0, les applets de commande et les fournisseurs ont été empaquetés dans les composants logiciels enfichables PowerShell. À compter de PowerShell 3.0, le composant logiciel enfichable Microsoft.PowerShell.Core est ajouté à chaque session par défaut. Il s’agit du seul composant logiciel enfichable restant dans PowerShell. Tous les autres composants logiciels enfichables ont été convertis en modules. La création de nouveaux composants logiciels enfichables n’est plus prise en charge.
Emplacements de module par défaut
PowerShell stocke les modules dans les emplacements par défaut suivants :
- Étendue de tous les utilisateurs -
$env:ProgramFiles\WindowsPowerShell\Modules - Étendue de l’utilisateur actuel -
$HOME\Documents\WindowsPowerShell\Modules - Modules fournis avec PowerShell -
$PSHOME\Modules
Par défaut, le Modules dossier de l’utilisateur actuel n’existe pas. Si vous avez installé un module dans l’étendue à l’aide CurrentUser Install-Module ou Install-PSResource, ces applets de commande créent le Modules dossier de l’utilisateur actuel. Si le dossier n’existe pas, vous pouvez le créer manuellement.
Utilisez la commande suivante pour créer un Modules dossier pour l’utilisateur actuel :
$folder = New-Item -Type Directory -Path $HOME\Documents\WindowsPowerShell\Modules
Ces emplacements sont automatiquement inclus dans la variable d’environnement $env:PSModulePath . Pour plus d’informations sur les emplacements de module par défaut, consultez about_PSModulePath.
Chargement automatique du module
La première fois que vous exécutez une commande à partir d’un module installé, PowerShell importe automatiquement (charge) ce module. Le module doit être stocké dans les emplacements spécifiés dans la variable d’environnement $env:PSModulePath .
Le chargement automatique du module vous permet d’utiliser des commandes dans un module sans configuration de configuration ou de profil. Chacun des exemples suivants entraîne l’importation du module CimCmdlets , qui contient Get-CimInstance, dans votre session.
Exécuter la commande
Get-CimInstance Win32_OperatingSystemObtenir la commande
Get-Command Get-CimInstanceObtenir de l’aide pour la commande
Get-Help Get-CimInstance
Lorsque vous utilisez Get-Command un caractère générique (*), PowerShell n’importe aucun module. Vous pouvez utiliser des caractères génériques pour la découverte de commandes sans charger de modules dont vous n’avez peut-être pas besoin dans votre session.
Importer manuellement un module
L’importation manuelle d’un module est requise lorsqu’un module n’est pas installé dans les emplacements spécifiés par la $env:PSModulePath variable d’environnement, ou lorsque le module est fourni en tant que fichier ou .psm1 autonome.dll, plutôt qu’un module empaqueté.
En outre, les commandes qui utilisent des fournisseurs PowerShell n’importent pas automatiquement un module. Par exemple, si vous utilisez une commande qui nécessite le WSMan: lecteur, comme l’applet Get-PSSessionConfiguration de commande, vous devrez peut-être exécuter l’applet Import-Module de commande pour importer le module Microsoft.WSMan.Management qui inclut le WSMan: lecteur.
Vous pouvez également modifier la façon dont le module est importé dans votre session. Par exemple, le paramètre Préfixe d’ajout Import-Module d’un préfixe distinctif à la partie nom des applets de commande importées à partir du module. Le paramètre NoClobber empêche le module d’ajouter des commandes qui masquent ou remplacent les commandes existantes dans la session. Pour plus d’informations, consultez Gérer les conflits de noms.
L’exemple suivant importe le module BitsTransfer dans la session active.
Import-Module BitsTransfer
Pour importer un module qui n’est pas dans votre $env:PSModulePathfichier, utilisez le chemin d’accès complet au dossier du module. Par exemple, pour ajouter le module TestCmdlets dans le C:\ps-test répertoire à votre session, tapez :
Import-Module C:\ps-test\TestCmdlets
Pour importer un fichier de module qui n’est pas contenu dans un dossier de module, utilisez le chemin d’accès complet au fichier de module dans la commande. Par exemple, pour ajouter le module TestCmdlets.dll dans le C:\ps-test répertoire à votre session, tapez :
Import-Module C:\ps-test\TestCmdlets.dll
Pour plus d’informations sur l’ajout de modules à votre session, consultez Import-Module.
Importer un module au début de chaque session
La Import-Module commande importe des modules dans votre session PowerShell actuelle. Pour importer un module dans chaque session PowerShell que vous démarrez, ajoutez la Import-Module commande à votre profil PowerShell.
Pour plus d'informations sur les profils, consultez about_Profiles.
Installer un module publié
Un module publié est un module disponible à partir d’un référentiel inscrit, tel que PowerShell Gallery. Les modules PowerShellGet et Microsoft.PowerShell.PSResourceGet fournissent des applets de commande pour rechercher, installer et publier des modules PowerShell dans un référentiel inscrit.
Le module PowerShellGet est inclus dans PowerShell 5.0 et versions ultérieures. Le module Microsoft.PowerShell.PSResourceGet est inclus dans PowerShell 7.4 et versions ultérieures et est le gestionnaire de package préféré pour PowerShell. Microsoft.PowerShell.PSResourceGet peut être installé, côte à côte avec PowerShellGet, sur les versions antérieures de PowerShell. Utilisez l’applet de commande ou Install-PSResource l’applet Install-Module de commande pour installer des modules à partir de PowerShell Gallery.
Get-Command Install-Module, Install-PSResource
CommandType Name Version Source
----------- ---- ------- ------
Function Install-Module 2.9.0 PowerShellGet
Cmdlet Install-PSResource 1.0.0 Microsoft.PowerShell.PSResourceGet
Pour plus d’informations, consultez Vue d’ensemble de PowerShellGet.
Installer manuellement un module
Vous pouvez installer manuellement un module en copiant le contenu du module à partir d’un autre dossier. Ce dossier peut se trouver à un autre emplacement sur l’ordinateur local ou installé sur un autre ordinateur. Pour installer un module manuellement, copiez l’intégralité du dossier du module dans un nouvel emplacement inclus dans votre $env:PSModulePath.
Dans PowerShell, utilisez l’applet de Copy-Item commande. Par exemple, exécutez la commande suivante pour copier le MyModule dossier à partir de C:\PSTest:
$modulePath = $HOME\Documents\PowerShell\Modules\MyModule
Copy-Item -Path C:\PSTest\MyModule\* -Destination $modulePath -Recurse
Vous pouvez installer vos modules n'importe où, mais nous vous recommandons de les installer dans un emplacement de module par défaut pour faciliter leur gestion.
Rechercher les modules installés
L’applet Get-Module de commande obtient les modules PowerShell chargés dans la session PowerShell actuelle.
Get-Module
Les modules répertoriés peuvent inclure des modules importés à partir de n’importe quel emplacement, pas seulement à partir de $env:PSModulePath.
Utilisez la commande suivante pour répertorier les modules installés dans les $env:PSModulePathéléments suivants :
Get-Module -ListAvailable
Cette commande obtient tous les modules installés dans $env:PSModulePath, pas seulement les modules importés dans la session active. Cette commande ne répertorie pas les modules installés dans d’autres emplacements.
Pour plus d’informations, consultez Get-Module.
Répertorier les commandes dans un module
Utilisez l’applet Get-Command de commande pour rechercher toutes les commandes disponibles. Vous pouvez utiliser les paramètres de l’applet Get-Command de commande pour filtrer des commandes telles que par module, nom et nom.
Pour rechercher toutes les commandes d’un module, tapez :
Get-Command -Module <module-name>
Par exemple, pour rechercher les commandes dans le module BitsTransfer , tapez :
Get-Command -Module BitsTransfer
Pour plus d’informations sur l’applet Get-Command de commande, consultez Get-Command.
Supprimer un module
Quand vous supprimez un module, les commandes ajoutées par le module sont supprimées de la session. Par exemple, la commande suivante supprime le module BitsTransfer de la session active.
Remove-Module BitsTransfer
Le fait de supprimer un module annule l'opération d'importation d'un module. La suppression d’un module ne désinstalle pas le module. Pour plus d’informations, consultez Remove-Module.
Les commandes peuvent être ajoutées à votre session à partir de modules et de composants logiciels enfichables. Les modules peuvent ajouter tous les types de commandes, notamment les applets de commande, les fournisseurs et les fonctions, ainsi que des éléments, tels que des variables, des alias et des lecteurs PowerShell. Les composants logiciels enfichables peuvent uniquement ajouter des applets de commande et des fournisseurs.
Avant de supprimer un module de votre session, utilisez les commandes suivantes pour déterminer le module que vous souhaitez supprimer.
Par exemple, utilisez la commande suivante pour rechercher la source des applets de commande et Get-Help les Get-Date applets de commande :
Get-Command Get-Date, Get-Help -All |
Select-Object -Property Name, CommandType, Module ,PSSnapIn
La sortie suivante montre que l’applet Get-Help de commande se trouve dans le composant logiciel enfichable Microsoft.PowerShell.Core . Ce composant logiciel enfichable ne peut pas être supprimé de la session.
Name CommandType Module PSSnapIn
---- ----------- ------ --------
Get-Date Function
Get-Date Cmdlet Microsoft.PowerShell.Utility
Get-Help Cmdlet Microsoft.PowerShell.Core
Il existe deux sources pour Get-Date. L’une est une fonction et l’autre est une applet de commande dans le module Microsoft.PowerShell.Utility . Vous pouvez supprimer le module à l’aide Remove-Modulede . Pour supprimer la fonction, vous pouvez la supprimer du Function: lecteur.
Remove-Item Function:Get-Date
Pour plus d’informations sur le Function: lecteur, consultez about_Function_Provider.
Gérer les conflits de noms
Des conflits de noms se produisent quand plusieurs commandes portent le même nom dans la session. Quand vous importez un module, un conflit survient si les noms des commandes de ce module sont identiques à ceux de commandes ou d'éléments présents dans la session.
Import-Module peut ajouter des commandes qui masquent et remplacent des commandes dans la session active. Les conflits de noms peuvent entraîner le masquage ou le remplacement de commandes. Le remplacement de commande se produit lorsque le module importé contient une commande portant le même nom qu’une commande existante dans la session. La commande nouvellement importée est prioritaire sur la commande existante.
Par exemple, lorsqu’une session inclut une fonction et une applet de commande portant le même nom, PowerShell exécute la fonction par défaut. Quand la session inclut des commandes du même type avec le même nom, par exemple deux applets de commande avec le même nom, la commande la plus récemment ajoutée est exécutée par défaut.
Pour plus d’informations, notamment une explication des règles de précédence et des instructions pour l’exécution de commandes masquées, consultez about_Command_Precedence.
Vous pouvez exécuter une commande masquée ou remplacée en qualifier le nom de la commande. Pour qualifier le nom de la commande, ajoutez le nom du module qui contient la version de la commande souhaitée. Par exemple :
Microsoft.PowerShell.Utility\Get-Date
L’exécution Get-Date avec le préfixe de nom du module garantit l’exécution de la version à partir du module Microsoft.PowerShell.Utility .
Pour détecter les conflits de noms, utilisez le paramètre All de l’applet Get-Command de commande. Par défaut, Get-Command obtient uniquement les commandes qui s’exécutent lorsque vous tapez le nom de la commande. Le paramètre All obtient toutes les commandes portant le nom spécifique dans la session.
Pour éviter les conflits de noms, utilisez les paramètres NoClobber ou Préfixe de l’applet Import-Module de commande. Le paramètre Préfixe ajoute un préfixe aux noms des commandes importées afin qu’ils soient uniques dans la session. Le paramètre NoClobber n’importe aucune commande qui masquerait ou remplacerait les commandes existantes dans la session.
Vous pouvez également utiliser les paramètres Alias, Applet de commande, Fonction et Variable pour Import-Module sélectionner uniquement les commandes que vous souhaitez importer, et vous pouvez exclure des commandes qui provoquent des conflits de noms dans votre session.
Les auteurs de modules peuvent empêcher les conflits de noms à l’aide de la propriété DefaultCommandPrefix du manifeste du module pour ajouter un préfixe par défaut à tous les noms de commandes. La valeur du paramètre Prefix est prioritaire sur la valeur de DefaultCommandPrefix.
