Я хочу создать прослушиватель в PowerShell, который может выполнять действие при импорте произвольного модуля PowerShell.
Есть ли какое-либо событие .net или событие WMI, которое вызывается при импорте модуля (вручную или автоматически), который я могу перехватить, а затем предпринять действие, если импортируемый модуль соответствует некоторым критериям?
Вещи, которые я нашел до сих пор, которые могут быть компонентами решения
Context
Я хочу раздвинуть границы аспектно-ориентированного программирования / разделения задач / DRY в PowerShell, где такие вещи, как состояние модуля (ключи API, корневые URL-адреса API, учетные данные, строки подключения к базе данных и т. Д.), Можно настроить с помощью функций set. это только изменяет состояние внутренних переменных в области памяти модуля, так что внешняя система может извлечь эти значения из любого произвольного средства сохранения (psd1, PSCustomObject, реестра, переменных среды, json, yaml, запроса к базе данных и т. д., вызова веб-службы, все остальное, что соответствует вашей конкретной среде).
Проблема продолжает появляться в модулях, которые мы пишем, и становится еще более болезненной при попытке поддержки кроссплатформенного ядра powershell, где различные средства сохранения могут быть недоступны (например, реестр), но могут быть лучшим вариантом для некоторых людей. в их среде (групповая политика, выдвигающая ключи реестра).
Поддержка бесконечно изменяемых средств сохранения конфигурации в каждом написанном модуле - неправильный способ справиться с этим, но это то, что делается во многих модулях сегодня, что приводит к различным уровням совместимости не потому, что функциональность ядра не работает, а просто из-за того, как модуль сохраняется и получает информацию о конфигурации.
Метод сохранения и последующей загрузки некоторой произвольной конфигурации модуля должен быть независимым от реализации модуля, но для этого мне нужен способ узнать, когда модуль загружен, чтобы я мог инициировать извлечение соответствующих значений из любой правильной персистентности. механизм находится в конкретной среде, в которой мы находимся, чтобы затем сконфигурировать модуль в соответствующем состоянии.
Пример того, как я думаю, что это может сработать, может быть, есть событие .net на объекте пространства выполнения, которое запускается при загрузке модуля. Это может быть связано с событием WMI, которое выполняется каждый раз при создании экземпляра пространства выполнения PowerShell. Если бы у нас был модуль PowerShellConfiguration, который знал, на какие модули он был настроен для загрузки конфигурации, то событие wmi могло бы инициировать импорт модуля PowerShellConfiguration, который при импорте начал бы слушать событие .net для импорта модулей в пространство выполнения и вызывать различные связанные с конфигурацией методы Set модуля, когда он видит импортированный модуль.