Freigeben über

Schreiben eines PowerShell-Binärmoduls

Ein binäres Modul kann eine beliebige Assembly (.dll) sein, die Cmdlet-Klassen enthält. Standardmäßig werden alle Cmdlets in der Assembly importiert, wenn das Binäre Modul importiert wird. Sie können jedoch die Cmdlets einschränken, die importiert werden, indem Sie ein Modulmanifest erstellen, dessen Stammmodul die Assembly ist. (Der CmdletsToExport-Schlüssel des Manifests kann beispielsweise verwendet werden, um nur die erforderlichen Cmdlets zu exportieren.) Darüber hinaus kann ein binäres Modul zusätzliche Dateien, eine Verzeichnisstruktur und andere nützliche Verwaltungsinformationen enthalten, die ein einzelnes Cmdlet nicht ausführen kann.

Das folgende Verfahren beschreibt, wie Sie ein PowerShell-Binärmodul erstellen und installieren.

Erstellen und Installieren eines PowerShell-Binärmoduls

  1. Erstellen Sie eine binäre PowerShell-Lösung (z. B. ein in C# geschriebenes Cmdlet), mit den benötigten Funktionen, und stellen Sie sicher, dass sie ordnungsgemäß ausgeführt wird.

    Aus Codeperspektive ist der Kern eines binären Moduls eine Cmdlet-Assembly. Tatsächlich behandelt PowerShell eine einzelne Cmdlet-Assembly als Modul zum Laden und Entladen, ohne zusätzlichen Aufwand für den Teil des Entwicklers. Weitere Informationen zum Schreiben eines Cmdlets finden Sie unter Schreiben eines Windows PowerShell-Cmdlets.

  2. Erstellen Sie bei Bedarf die restliche Lösung: (zusätzliche Cmdlets, XML-Dateien usw.) und beschreiben Sie sie mit einem Modulmanifest.

    Neben der Beschreibung der Cmdlet-Assemblys in Ihrer Lösung kann ein Modulmanifest beschreiben, wie Das Modul exportiert und importiert werden soll, welche Cmdlets verfügbar gemacht werden und welche zusätzlichen Dateien in das Modul eingefügt werden. Wie bereits erwähnt, kann PowerShell jedoch ein binäres Cmdlet wie ein Modul ohne zusätzlichen Aufwand behandeln. Daher eignet sich ein Modulmanifest hauptsächlich für die Kombination mehrerer Dateien in ein einzelnes Paket oder für die explizite Steuerung der Publikation für eine bestimmte Assembly. Weitere Informationen finden Sie unter Schreiben eines PowerShell-Modulmanifests.

    Der folgende Code ist ein vereinfachtes C#-Beispiel, das drei Cmdlets in derselben Datei enthält, die als Modul verwendet werden kann.

    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. Packen Sie Ihre Lösung, und speichern Sie das Paket an einer beliebigen Stelle im PowerShell-Modulpfad.

    Die $env:PSModulePath globale Umgebungsvariable beschreibt die Standardpfade, die PowerShell zum Suchen Ihres Moduls verwendet. Ein allgemeiner Pfad zum Speichern eines Moduls auf einem System wäre z. B. %SystemRoot%\Users\<user>\Documents\WindowsPowerShell\Modules\<moduleName>. Wenn Sie die Standardpfade nicht verwenden, müssen Sie den Speicherort Des Moduls während der Installation explizit angeben. Achten Sie darauf, einen Ordner zu erstellen, in dem Ihr Modul gespeichert werden kann, da Sie möglicherweise den Ordner zum Speichern mehrerer Assemblys und Dateien für Ihre Lösung benötigen.

    Technisch gesehen müssen Sie Ihr Modul nicht an einer beliebigen Stelle $env:PSModulePath installieren – dies sind einfach die Standardspeicherorte, die PowerShell nach Ihrem Modul sucht. Es wird jedoch als bewährte Methode betrachtet, dies zu tun, es sei denn, Sie haben einen guten Grund, Ihr Modul an einer anderen Stelle zu speichern. Weitere Informationen finden Sie unter Installieren eines PowerShell-Moduls und about_PSModulePath.

  4. Importieren Sie Ihr Modul mit einem Aufruf von Import-Module-in PowerShell.

    Das Aufrufen des Importmoduls lädt Das Modul in den aktiven Arbeitsspeicher. Wenn Sie PowerShell 3.0 und höher verwenden, importiert auch das Aufrufen eines Befehls aus Ihrem Modul im Code. Weitere Informationen finden Sie unter Importieren eines PowerShell-Moduls.

Modulinitialisierungs- und Bereinigungscode

Wenn Ihr Modul beim Importieren oder Entfernen etwas tun muss, z. B. eine Ermittlungsaufgabe oder Initialisierung, können Sie die und IModuleAssemblyInitializer die IModuleAssemblyCleanup Schnittstellen implementieren.

Hinweis

Dieses Muster wird nur dann abgeraten, wenn es unbedingt erforderlich ist. Um die Leistung von PowerShell aufrechtzuerhalten, sollten Sie dinge an dem Punkt laden, an dem Ihre Befehle aufgerufen werden, anstatt beim Import.

Importieren von Snap-In-Assemblys als Module

Cmdlets und Anbieter, die in Snap-In-Assemblys vorhanden sind, können als Binärmodule geladen werden. Wenn die Snap-In-Assemblys als Binärmodule geladen werden, sind die Cmdlets und Anbieter im Snap-In für den Benutzer verfügbar, die Snap-In-Klasse in der Assembly wird jedoch ignoriert, und das Snap-In wird nicht registriert. Daher können die von Windows PowerShell bereitgestellten Snap-In-Cmdlets das Snap-In nicht erkennen, obwohl die Cmdlets und Anbieter für die Sitzung verfügbar sind.

Darüber hinaus können formatierungs- oder typendateien, auf die vom Snap-In verwiesen wird, nicht als Teil eines binären Moduls importiert werden. Zum Importieren der Formatierungs- und Typendateien müssen Sie ein Modulmanifest erstellen. Weitere Informationen finden Sie unter Schreiben eines PowerShell-Modulmanifests.

Siehe auch

  • Last updated on