我看过this document,它列出了$Env:ProgramFiles\WindowsPowerShell\Modules
(%ProgramFiles%\WindowsPowerShell\Modules
)作为为所有用户安装模块的好地方。关于命名,它说:
使用正确的模块目录名称
“格式正确”的模块是存储在以下目录中的模块: 与模块中至少一个文件的基本名称同名 目录。如果模块格式不正确,则Windows PowerShell不会 将其识别为模块。
文件的“基本名称”是不带文件扩展名的名称。 在格式正确的模块中,包含以下内容的目录名称: 模块文件必须与至少一个文件的基本名称匹配, 模块。
例如,在示例Fabrikam模块中,该目录 包含名为“ Fabrikam”的模块文件和至少一个文件 具有“ Fabrikam”的基本名称。在这种情况下,Fabrikam.psd1和 Fabrikam.dll具有“ Fabrikam”的基本名称。
C:\Program Files Fabrikam Technologies Fabrikam Manager Modules Fabrikam Fabrikam.psd1 (module manifest) Fabrikam.dll (module assembly)
但是,我仍然不清楚。假设我有一个由ABC.psd1
和ABC.psm1
组成的模块。我是否正确理解应将其安装在$Env:ProgramFiles\WindowsPowerShell\Modules\ABC
中,并将.psd1和.psm1直接放在该目录下?
例如,我看一些Microsoft模块:
C:\Program Files
WindowsPowerShell
Modules
AzureRM
5.7.0
AzureRM[.psd1,psm1]
因此,至少基于引用的文档,它违反了“格式正确的模块”的规则,因为该语句似乎不允许使用该5.7.0
目录,或者不涉及递归搜索。那是专门用于版本控制的层次结构,是开发人员选择的吗?即使是版本控制,它也不符合上述文档中的建议,因为“使用模块的多个版本”建议将其添加到目录名称中,而不是作为子目录添加。
我的问题的要点是:
在嵌套方面,关于powershell如何在此目录中搜索模块有更好的解释吗?
假设随着产品的增长,我有了第二个模块DEF.psd1
。我应该归入公司文件夹还是产品文件夹,并且所有版本的Powershell对此都满意(也就是说,无需更改PSModulePath)。
例如:
C:\Program Files
WindowsPowerShell
Modules
My Company
ABC
ABC[.psd1,psm1]
DEF
DEF[.psd1,psm1]
我希望支持Powershell 3.0及更高版本。另外,我注意到Powershell ISE模块浏览器使用的搜索规则与powershell本身不同。例如,使用我建议的带有公司名称的层次结构在Powershell,ISE和用户脚本中可以很好地工作,但是会破坏ISE模块浏览器,当单击“显示详细信息”时,该浏览器会给出“找不到模块”错误。
答案 0 :(得分:0)
看起来很像您已经回答了这个问题。不确定AzureRM模块为何/如何具有版本控制文件夹...但是该模块是由Microsoft创建的,因此他们可能知道一个漏洞。
根据我的经验和所阅读的文档,示例中的文件结构正确,只是没有“我的公司”文件夹。如何命名文件夹和.psm1 / psd1文件(具有相同的基本名称)是正确的。实际上,对于基于脚本的最小模块,您只需要.psm1文件,它就可以工作(加载文件中的所有功能),尽管使用New-ModuleManifest生成模块文件不会受到影响。如评论中所述,然后可以通过PowerShell在.psd1文件中跟踪和识别版本。
现在,我从来没有为所有用户在ProgramFiles文件夹中放置一个模块,但我想它所使用的规则与基于用户的文件夹使用相同的规则(它们只是powershell所查看的环境变量中的路径)。
我还将以下链接用作构建易于维护的PowerShell模块的方法或模板: http://ramblingcookiemonster.github.io/Building-A-PowerShell-Module/
您可以忽略不感兴趣或不使用的部分(用于测试或视图的文件夹或使用Git存储库)...基本结构以及使用.psm1文件加载单个功能的技术