Как написать бинарный модуль PowerShell

Двоичный модуль может быть любой сборкой (.dll), содержащей классы командлетов. По умолчанию все командлеты в сборке импортируются при импорте двоичного модуля. Однако можно ограничить командлеты, импортированные путем создания манифеста модуля, корневой модуль которого является сборкой. (Например, ключ CmdletsToExport манифеста можно использовать для экспорта только тех командлетов, которые необходимы.) Кроме того, двоичный модуль может содержать дополнительные файлы, структуру каталогов и другие полезные сведения об управлении, которые не удается одному командлету.

В следующей процедуре описывается создание и установка двоичного модуля PowerShell.

Создание и установка двоичного модуля PowerShell

1. Создайте двоичное решение PowerShell (например, командлет, написанный на C#), с нужными возможностями и убедитесь, что она работает правильно.

   С точки зрения кода ядро двоичного модуля — это сборка командлета. На самом деле PowerShell рассматривает одну сборку командлета как модуль для загрузки и выгрузки без дополнительных усилий со стороны разработчика. Дополнительные сведения о написании командлета см. в записи командлета Windows PowerShell.

2. При необходимости создайте остальную часть решения: (дополнительные командлеты, XML-файлы и т. д.) и опишите их манифестом модуля.

   Помимо описания сборок командлетов в решении, манифест модуля может описать, как вы хотите экспортировать и импортировать модуль, какие командлеты будут предоставляться, а также какие дополнительные файлы будут использоваться в модуле. Как уже упоминалось ранее, PowerShell может обрабатывать двоичный командлет как модуль без дополнительных усилий. Таким образом, манифест модуля полезен главным образом для объединения нескольких файлов в один пакет или для явного управления публикацией для данной сборки. Дополнительные сведения см. в статье Создание манифеста модуля PowerShell.

   Следующий код — это упрощенный пример C#, содержащий три командлета в одном файле, который можно использовать в качестве модуля.

   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. Упаковайте решение и сохраните пакет где-то в пути модуля PowerShell.

   Глобальная $env:PSModulePath переменная среды описывает пути по умолчанию, используемые PowerShell для поиска модуля. Например, общий путь для сохранения модуля в системе будет %SystemRoot%\Users\<user>\Documents\WindowsPowerShell\Modules\<moduleName>. Если вы не используете пути по умолчанию, необходимо явно указать расположение модуля во время установки. Не забудьте создать папку для сохранения модуля, так как может потребоваться папка для хранения нескольких сборок и файлов для решения.

   Технически вам не нужно устанавливать модуль в любом месте $env:PSModulePath . Это просто расположения по умолчанию, в которых PowerShell будет искать модуль. Тем не менее, рекомендуется сделать это, если у вас нет хорошей причины для хранения модуля в другом месте. Дополнительные сведения см. в статье Установка модуля PowerShell и about_PSModulePath.

4. Импорт модуля в PowerShell с вызовом import-Module.

   Вызов импорта модуля загружает модуль в активную память. Если вы используете PowerShell 3.0 и более поздних версий, вызов команды из модуля в коде также импортирует его. Дополнительные сведения см. в статье Импорт модуля PowerShell.

Код инициализации модуля и очистки

Если модуль должен выполнить что-то при импорте или удалении, например задачи обнаружения или инициализации, можно реализовать IModuleAssemblyInitializer интерфейсы и IModuleAssemblyCleanup интерфейсы.

Импорт сборок оснастки в виде модулей

Командлеты и поставщики, которые существуют в сборках оснастки, можно загрузить в виде двоичных модулей. Когда сборки оснастки загружаются в виде двоичных модулей, командлеты и поставщики в оснастке доступны пользователю, но класс оснастки в сборке игнорируется, а оснастка не зарегистрирована. В результате командлеты оснастки, предоставляемые Windows PowerShell, не могут обнаруживать оснастки, даже если командлеты и поставщики доступны для сеанса.

Кроме того, любые файлы форматирования или типов, на которые ссылается оснастка, нельзя импортировать как часть двоичного модуля. Чтобы импортировать файлы форматирования и типов, необходимо создать манифест модуля. См. , как записать манифест модуля PowerShell.

См. также

• написание модуля Windows PowerShell