Partager via

Guide pratique pour écrire un module binaire PowerShell

  • Article

Un module binaire peut être n’importe quel assembly (.dll) qui contient des classes d’applet de commande. Par défaut, toutes les applets de commande de l’assembly sont importées lorsque le module binaire est importé. Toutefois, vous pouvez restreindre les applets de commande importées en créant un manifeste de module dont le module racine est l’assembly. (Par exemple, la clé CmdletsToExport du manifeste peut être utilisée pour exporter uniquement les applets de commande nécessaires.) En outre, un module binaire peut contenir des fichiers supplémentaires, une structure de répertoires et d’autres éléments d’informations de gestion utiles qu’une seule applet de commande ne peut pas utiliser.

La procédure suivante décrit comment créer et installer un module binaire PowerShell.

Comment créer et installer un module binaire PowerShell

  1. Créez une solution PowerShell binaire (par exemple, une applet de commande écrite en C#), avec les fonctionnalités dont vous avez besoin et assurez-vous qu’elle s’exécute correctement.

    Du point de vue du code, le cœur d’un module binaire est simplement un assembly d’applet de commande. En fait, PowerShell traite un seul assembly d’applet de commande en tant que module, en termes de chargement et de déchargement, sans effort supplémentaire de la part du développeur. Pour plus d’informations sur l’écriture d’une applet de commande, consultez Écriture d’une applet de commande Windows PowerShell.

  2. Si nécessaire, créez le reste de votre solution : (applets de commande supplémentaires, fichiers XML, et ainsi de suite) et décrivez-les avec un manifeste de module.

    En plus de décrire les assemblys d’applet de commande dans votre solution, un manifeste de module peut décrire la façon dont vous souhaitez que votre module soit exporté et importé, quelles applets de commande seront exposées et quels fichiers supplémentaires passeront dans le module. Comme indiqué précédemment, PowerShell peut traiter une applet de commande binaire comme un module sans effort supplémentaire. Par conséquent, un manifeste de module est utile principalement pour combiner plusieurs fichiers en un seul package ou pour contrôler explicitement la publication d’un assembly donné. Pour plus d’informations, consultez Comment écrire un manifeste de module PowerShell.

    Le code suivant est un bloc de code C# extrêmement simple qui contient trois applets de commande dans le même fichier que celui qui peut être utilisé comme module.

    using System.Management.Automation;           // Windows PowerShell namespace.

namespace ModuleCmdlets
{
  [Cmdlet(VerbsDiagnostic.Test,"BinaryModuleCmdlet1")]
  public class TestBinaryModuleCmdlet1Command : Cmdlet
  {
    protected override void BeginProcessing()
    {
      WriteObject("BinaryModuleCmdlet1 exported by the ModuleCmdlets module.");
    }
  }

  [Cmdlet(VerbsDiagnostic.Test, "BinaryModuleCmdlet2")]
  public class TestBinaryModuleCmdlet2Command : Cmdlet
  {
      protected override void BeginProcessing()
      {
          WriteObject("BinaryModuleCmdlet2 exported by the ModuleCmdlets module.");
      }
  }

  [Cmdlet(VerbsDiagnostic.Test, "BinaryModuleCmdlet3")]
  public class TestBinaryModuleCmdlet3Command : Cmdlet
  {
      protected override void BeginProcessing()
      {
          WriteObject("BinaryModuleCmdlet3 exported by the ModuleCmdlets module.");
      }
  }

}

  3. Empaqueter votre solution et enregistrer le package dans un emplacement dans le chemin du module PowerShell.

    La variable d’environnement globale PSModulePath décrit les chemins d’accès par défaut que PowerShell utilisera pour localiser votre module. Par exemple, un chemin d’accès commun pour enregistrer un module sur un système serait %SystemRoot%\Users\<user>\Documents\WindowsPowerShell\Modules\<moduleName>. Si vous n’utilisez pas les chemins d’accès par défaut, vous devez indiquer explicitement l’emplacement de votre module pendant l’installation. Veillez à créer un dossier dans lequel enregistrer votre module, car vous devrez peut-être stocker plusieurs assemblys et fichiers pour votre solution.

    Notez que techniquement, vous n’avez pas besoin d’installer votre module n’importe où sur l'PSModulePath : il s’agit simplement des emplacements par défaut que PowerShell recherchera votre module. Toutefois, il est recommandé de le faire, sauf si vous avez une bonne raison de stocker votre module ailleurs. Pour plus d’informations, consultez Installation d’un module PowerShell et about_PSModulePath.

  4. Importez votre module dans PowerShell avec un appel à Import-Module .

    L’appel à import-module charge votre module en mémoire active. Si vous utilisez PowerShell 3.0 et versions ultérieures, l’appel du nom de votre module dans le code l’importera également ; Pour plus d’informations, consultez Importation d’un module PowerShell.

Importation d’assemblys enfichables en tant que modules

Les applets de commande et les fournisseurs qui existent dans les assemblys enfichables peuvent être chargés en tant que modules binaires. Lorsque les assemblys enfichables sont chargés en tant que modules binaires, les applets de commande et les fournisseurs du composant logiciel enfichable sont disponibles pour l’utilisateur, mais la classe de composant logiciel enfichable dans l’assembly est ignorée et le composant logiciel enfichable n’est pas inscrit. Par conséquent, les applets de commande de composant logiciel enfichable fournies par Windows PowerShell ne peuvent pas détecter le composant logiciel enfichable même si les applets de commande et les fournisseurs sont disponibles pour la session.

En outre, les fichiers de mise en forme ou de types référencés par le composant logiciel enfichable ne peuvent pas être importés dans le cadre d’un module binaire. Pour importer les fichiers de mise en forme et de types, vous devez créer un manifeste de module. Consultez Comment écrire un manifeste de module PowerShell.

Voir aussi

écrire un de module Windows PowerShell