Condividi tramite


Come scrivere un modulo binario di PowerShell

Un modulo binario può essere qualsiasi assembly (.dll) che contiene classi di cmdlet. Per impostazione predefinita, tutti i cmdlet nell'assembly vengono importati quando viene importato il modulo binario. Tuttavia, è possibile limitare i cmdlet importati creando un manifesto del modulo il cui modulo radice è l'assembly. Ad esempio, la chiave CmdletsToExport del manifesto può essere usata per esportare solo i cmdlet necessari. Inoltre, un modulo binario può contenere file aggiuntivi, una struttura di directory e altre informazioni utili sulla gestione che un singolo cmdlet non può.

La procedura seguente descrive come creare e installare un modulo binario di PowerShell.

Come creare e installare un modulo binario di PowerShell

  1. Creare una soluzione PowerShell binaria (ad esempio un cmdlet scritto in C#), con le funzionalità necessarie e assicurarsi che funzioni correttamente.

    Dal punto di vista del codice, il nucleo di un modulo binario è un assembly di cmdlet. PowerShell considera infatti un singolo assembly di cmdlet come un modulo per il caricamento e lo scaricamento, senza ulteriori sforzi da parte dello sviluppatore. Per altre informazioni sulla scrittura di un cmdlet, vedere Scrittura di un cmdlet di Windows PowerShell.

  2. Se necessario, creare il resto della soluzione: (cmdlet aggiuntivi, file XML e così via) e descriverli con un manifesto del modulo.

    Oltre a descrivere gli assembly dei cmdlet nella soluzione, un manifesto del modulo può descrivere come si vuole esportare e importare il modulo, quali cmdlet verranno esposti e quali file aggiuntivi verranno inseriti nel modulo. Come indicato in precedenza, tuttavia, PowerShell può trattare un cmdlet binario come un modulo senza ulteriori sforzi. Di conseguenza, un manifesto del modulo è utile principalmente per combinare più file in un singolo pacchetto o per controllare in modo esplicito la pubblicazione per un determinato assembly. Per altre informazioni, vedere Come scrivere un manifesto del modulo di PowerShell.

    Il codice seguente è un esempio C# semplificato che contiene tre cmdlet nello stesso file che può essere usato come modulo.

    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. Creare un pacchetto della soluzione e salvare il pacchetto in un punto qualsiasi nel percorso del modulo di PowerShell.

    La $env:PSModulePath variabile di ambiente globale descrive i percorsi predefiniti usati da PowerShell per individuare il modulo. Ad esempio, un percorso comune per salvare un modulo in un sistema sarà %SystemRoot%\Users\<user>\Documents\WindowsPowerShell\Modules\<moduleName>. Se non si usano i percorsi predefiniti, è necessario specificare in modo esplicito il percorso del modulo durante l'installazione. Assicurarsi di creare una cartella in cui salvare il modulo, perché potrebbe essere necessaria la cartella per archiviare più assembly e file per la soluzione.

    Tecnicamente, non è necessario installare il modulo da nessuna parte di $env:PSModulePath . Questi sono semplicemente i percorsi predefiniti che PowerShell cercherà il modulo. Tuttavia, è consigliabile farlo, a meno che non si abbia un buon motivo per archiviare il modulo in un'altra posizione. Per altre informazioni, vedere Installazione di un modulo di PowerShell e about_PSModulePath.

  4. Importare il modulo in PowerShell con una chiamata a Import-Module.

    La chiamata a Import-Module carica il modulo nella memoria attiva. Se si usa PowerShell 3.0 e versioni successive, richiamare anche un comando dal modulo nel codice. Per altre informazioni, vedere Importazione di un modulo di PowerShell.

Codice di inizializzazione e pulizia del modulo

Se il modulo deve eseguire operazioni durante l'importazione o la rimozione, ad esempio un'attività di individuazione o un'inizializzazione, è possibile implementare le IModuleAssemblyInitializer interfacce e IModuleAssemblyCleanup .

Annotazioni

Questo modello è sconsigliato a meno che non sia assolutamente necessario. Per garantire prestazioni elevate di PowerShell, è consigliabile caricare in modo differitivo gli elementi nel momento in cui i comandi vengono chiamati anziché in fase di importazione.

Importazione di assembly snap-in come moduli

I cmdlet e i provider esistenti negli assembly snap-in possono essere caricati come moduli binari. Quando gli assembly snap-in vengono caricati come moduli binari, i cmdlet e i provider nello snap-in sono disponibili per l'utente, ma la classe snap-in nell'assembly viene ignorata e lo snap-in non viene registrato. Di conseguenza, i cmdlet snap-in forniti da Windows PowerShell non riescono a rilevare lo snap-in anche se i cmdlet e i provider sono disponibili per la sessione.

Inoltre, eventuali file di formattazione o tipi a cui fa riferimento lo snap-in non possono essere importati come parte di un modulo binario. Per importare i file di formattazione e tipi, è necessario creare un manifesto del modulo. Vedere Come scrivere un manifesto del modulo di PowerShell.

Vedere anche