在导入PowerShell模块时，我可以挂钩哪些事件（.net，WMI等）来执行操作？

Question

我想在PowerShell中创建一个侦听器，可以在导入任意PowerShell模块时执行操作。

是否有任何.net事件或WMI事件在模块导入期间（手动或自动）触发，如果导入的模块符合某些条件，我可以挂钩然后执行操作？

到目前为止，我发现的可能是解决方案的组成部分

• Module event logging
• Runspace pool state changed
• Triggering PowerShell when event log entry is created
  • 也许不是直接有用，但是如果我们可以在正在运行的PowerShell流程中挂钩同一个事件，那可能会有帮助
• Use PowerShell profile加载PowerShellConfiguration模块
• 为Import-Module创建proxy function以检查正在导入的模块是否与需要为其加载的配置的模块匹配
  • 在测试中，在自动加载导入模块时不会调用Import-Module，因此这不会捕获每个导入的模块

上下文

我想在PowerShell中突破面向方面编程/关注/ DRY分离的限制，其中模块状态（API密钥，API根URL，凭证，数据库连接字符串等）都可以通过set函数设置只更改内存模块作用域内部变量的状态，以便外部系统可以从任意持久性方式中提取这些值（psd1，PSCustomObject，注册表，环境变量，json，yaml，数据库查询，等等，Web服务调用，任何适合您特定环境的事物。）

问题不断出现在我们编写的模块中，并且在尝试支持PowerShell核心跨平台时会更加痛苦，因为可能无法使用不同的持久性方法（如注册表），但可能是某些人的最佳选择在他们的环境中（推送注册表项的组策略）。

在每个编写的模块中支持无限可变的持久配置方法是处理这个问题的错误方法，但是今天在许多模块中所做的是导致不同级别的兼容性，而不是因为核心功能不起作用而是仅仅是由于模块如何持久存在并检索配置信息。

持久化然后加载一些任意模块配置的方法应该独立于模块的实现，但为此我需要一种方法来知道何时加载模块，以便我可以触发从任何正确的持久性中提取适当的值机制在我们所处的特定环境中，然后使用适当的状态配置模块。

我认为这可能有用的一个例子可能是在加载模块时触发的运行空间对象上有一个.net事件。这可能必须绑定到每次实例化PowerShell运行空间时执行的WMI事件。如果我们有一个PowerShellConfiguration模块，它知道已经设置了哪些模块来加载配置，那么wmi事件可能会触发PowerShellConfiguration模块的导入，该模块在导入时会开始监听.net事件，以便将模块导入到运行空间并调用模块在看到模块导入时的各种配置相关Set方法。