Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Brève description
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 mots clés, qui fournissent la structure et la logique du 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, veuillez consulter la section 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 commande Remove-Module.
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 cmdlets et les fournisseurs étaient regroupés dans des snap-ins PowerShell. À partir de PowerShell 3.0, le snap-in Microsoft.PowerShell.Core est ajouté par défaut à chaque session. C’est le seul snap-in restant dans PowerShell. Tous les autres composants logiciels enfichables ont été convertis en modules. La création de nouveaux snap-ins n’est plus prise en charge.
Emplacements de module par défaut
PowerShell stocke les modules dans les emplacements par défaut suivants :
- Sous Windows
- Étendue pour tous les utilisateurs :
$Env:ProgramFiles\PowerShell\Modules - Étendue pour l’utilisateur actuel :
$HOME\Documents\PowerShell\Modules - Modules fournis avec PowerShell -
$PSHOME\Modules
- Étendue pour tous les utilisateurs :
- Sur Linux et macOS
- Étendue pour tous les utilisateurs :
/usr/local/share/powershell/Modules - Étendue pour l’utilisateur actuel :
$HOME/.local/share/powershell/Modules - Modules fournis avec PowerShell -
$PSHOME/Modules
- Étendue pour tous les utilisateurs :
Par défaut, le dossier Modules de l’utilisateur actuel n’existe pas. Si vous avez installé un module dans l’étendue CurrentUser à l’aide de Install-Module ou de Install-PSResource, ces applets de commande créent le dossier Modules pour l’utilisateur actuel. Si le dossier n’existe pas, vous pouvez le créer manuellement.
Utilisez la commande suivante pour créer un dossier Modules pour l’utilisateur actuel :
$folder = New-Item -Type Directory -Path $HOME\Documents\PowerShell\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 des modules vous permet d'utiliser des commandes dans un module sans configuration préalable ni 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 avec 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 variable d’environnement $Env:PSModulePath, ou lorsque le module est fourni en tant que fichier autonome .dll ou .psm1, 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 lecteur WSMan:, comme l’applet de commande Get-PSSessionConfiguration, vous devrez peut-être exécuter l’applet de commande Import-Module pour importer le module Microsoft.WSMan.Management qui inclut le lecteur WSMan:.
Vous pouvez également modifier la façon dont le module est importé dans votre session. Par exemple, le paramètre Préfixe de Import-Module ajoute un préfixe distinctif à la partie nominale 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:PSModulePath, utilisez le chemin complet du dossier du module. Par exemple, pour ajouter le module TestCmdlets dans le répertoire C:\ps-test à 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 répertoire C:\ps-test à 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 commande Import-Module importe des modules dans votre session PowerShell actuelle. Pour importer un module dans chaque session PowerShell que vous démarrez, ajoutez la commande Import-Module à 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 Install-Module ou Install-PSResource 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 commande Copy-Item. Par exemple, exécutez la commande suivante pour copier le dossier MyModule à partir de C:\PSTest:
$modulePath = $HOME\Documents\PowerShell\Modules\MyModule
Copy-Item -Path C:\PSTest\MyModule\* -Destination $modulePath -Recurse
Vous pouvez installer un module à n’importe quel emplacement, mais l’installation de vos modules dans un emplacement de module par défaut facilite leur gestion.
Rechercher les modules installés
L’applet de commande Get-Module 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 le $Env:PSModulePath:
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, veuillez consulter la section Get-Module.
Répertorier les commandes dans un module
Utilisez l’applet de commande Get-Command pour rechercher toutes les commandes disponibles. Vous pouvez utiliser les paramètres de l’applet de commande Get-Command pour filtrer des commandes par module, nom et nom commun.
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 de commande Get-Command, consultez Get-Command .
Supprimer un module
Lorsque 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
La suppression d’un module inverse l’opération d’importation d’un module. La suppression d’un module ne désinstalle pas le module. Pour plus d’informations, veuillez consulter la section 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 Get-Date et Get-Help :
Get-Command Get-Date, Get-Help -All |
Select-Object -Property Name, CommandType, Module ,PSSnapIn
La sortie suivante montre que la cmdlet Get-Help se trouve dans le snap-in Microsoft.PowerShell.Core. Ce snap-in 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 de Remove-Module. Pour supprimer la fonction, vous pouvez la supprimer du lecteur Function:.
Remove-Item Function:Get-Date
Pour plus d’informations sur le lecteur Function:, veuillez consulter la section about_Function_Provider.
Gérer les conflits de noms
Les conflits de noms se produisent lorsque plusieurs commandes de la session ont le même nom. L’importation d’un module provoque un conflit de noms lorsque les commandes du module ont les mêmes noms que les commandes ou les éléments de 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 des commandes masquées ou remplacées. 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. Lorsque la session inclut des commandes du même type portant le même nom, telles que deux applets de commande portant le même nom, par défaut, elle exécute la commande la plus récente ajoutée.
Pour plus d’informations, notamment une explication des règles de précédence et des instructions relatives à l’exécution de commandes masquées, consultez about_Command_Precedence.
Vous pouvez exécuter une commande masquée ou remplacée en qualifiant 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
Exécuter Get-Date avec le préfixe du nom de module garantit que vous exécutez la version provenant du module Microsoft.PowerShell.Utility.
Pour détecter les conflits de noms, utilisez le paramètre All de l’applet de commande Get-Command. 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 avec le nom spécifique dans la session.
Pour éviter les conflits de noms, utilisez les paramètres noClobber ou préfixe de l’applet de commande Import-Module. 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
Vous pouvez également utiliser les paramètres d'alias , de cmdlet , de fonction et de variable de Import-Module pour sélectionner uniquement les commandes que vous souhaitez importer, et vous pouvez exclure les 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 a priorité sur la valeur de DefaultCommandPrefix.
Voir aussi
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
