请添加您希望如何增强 PowerShell 语言以添加版本的信息。 在 cmdletbinding 属性中？

我的想法是做一些类似 New-ScriptFileInfo 的事情，它会生成一个这样的评论标题：

<#PSScriptInfo

.VERSION 1.0

.GUID 66c837b7-6478-4571-9dec-0621e13df4c3

.AUTHOR Jeff

.COMPANYNAME

.COPYRIGHT 2020

.TAGS

.LICENSEURI

.PROJECTURI

.ICONURI

.EXTERNALMODULEDEPENDENCIES 

.REQUIREDSCRIPTS

.EXTERNALSCRIPTDEPENDENCIES

.RELEASENOTES


.PRIVATEDATA

#>

<# 

.DESCRIPTION 
 This is a cool function 

#> 
Param()

将其设为 PSFunctionInfo 并让 Get-Command 对其进行解析。 或者像 PowerShell 可以解析 #requires 一样，让它解析 #version。 当你在同一个 ps1 文件中有多个函数时，它变得棘手，所以我作为函数作者所做的任何事情都需要包含在函数中。 这可能是一个解析的注释块、新的 cmdletbinding() 选项，或者可能是一个全新的属性。

Function Get-Awesomeness {

 [cmdletbinding()]
 [alias("awe")]
 [outputtype("psobject")]
 [version("1.1.0")]

 Param ()

 ...
}

我没有看到该功能的价值。 我们可以在 PowerShellGet 上发布并将 PowerShell 脚本仅作为模块分发，我们不能对文件执行此操作。 你能描述一个商业案例/工作流程吗？

有很多人创建了从未在图库中发布的 PowerShell 解决方案。 它们在内部使用，比如在公司环境中。 并不是所有的东西都打包成一个模块。 我可能在公司环境中工作，并且有一个带有函数的独立脚本文件。 我希望能够跟踪该功能的版本。 如果我运行 Get-Command Get-CompanyFoo，我需要能够看到版本号。 就此而言，即使在一个模块中，所有导出的函数共享相同的版本号。 我想要一个工具来跟踪每个功能的版本信息。 当然，不必依赖阅读源代码。 如果帮助台技术人员正在使用我的功能之一，他们需要能够使用 PowerShell 来发现命令版本。

当然，并不是每个函数都需要这个，即使是模块中的函数。 如果没有检测到特定于命令的版本，我对使用模块版本的模块中的函数没有问题。

@jdhitsolutions谢谢！

我在您的场景中看到了两个组件 - (1) 版本跟踪系统，(2) 分发系统。
第一个可能是 GIT（其他？）。
目前尚不清楚您如何分发脚本文件。

（我试图了解所请求属性的正确位置。）

我定期在客户处留下功能，这些功能是我上次在该特定客户处使用它们时的最新状态。 我今天在客户身上使用的一种方法让我想起了 - getWUlog。 它知道如何使用 WinRM 和 psexec 连接到远程系统（它会检查 139 或 5985 是否打开）并从该计算机检索 WindowsUpdate 日志，将其检索到本地计算机，然后打开记事本。

另一个是 getFrameworkVersion。 这样做 - 使用 CIM 或远程注册表服务（再次 - 检查端口以找出要执行的操作）寻找安装在给定计算机上的 .NET Framework 版本，报告这些，并报告哪些版本被阻止，如果有的话。

这些是独立的功能。 不是模块的一部分。 但他们在过去几年中定期更新。

为每个版本附加一个版本会很棒。 现在，我在源的顶部只有一个“上次修改日期”。 没那么好用...

在我看来，分发与本次讨论无关。 是的，git 发挥了作用，但不是问题。 如果我在 PowerShell 中并且正在使用独立函数。 当我运行 Get-Command Get-Foo 时，我想查看该函数的版本号。 它是如此简单。 函数如何分布并不重要。 给我一种将元数据注入函数的方法。

并且绝对清楚，我不想强​​迫用户，甚至我自己，追踪来源并寻找评论或注释。

我肯定会编写/使用一些独立的函数，但大多数都在模块中。 而且大多数都可以作为独立的功能随机废料工具。 我总是将语义版本和更改日志放在注释块中的.NOTES中，并在开始块中放置[version]$Version ，因为我想跟踪我对特定函数所做的更改，而不仅仅是到模块（当我对内部函数进行更改时我会增加）。 拥有像[version()]或[cmdletbinding(Version='01.00.0000')]这样的东西会很壮观； 我比 .VERSION 更喜欢它，因为我知道很多人将多个函数放入 psm1 文件中（尽管我没有）。
顺便说一句，我也使用 git，但我不会每次对单个函数进行更改时都提交； 我将它们捆绑起来并在更改模块时提交，通常将模块版本作为提交消息。 是的，是的，我知道，我很奇怪。

如果在$env:PATH找到脚本，它确实会出现在 Get-Command 中。 因此，将现有的 ScriptFileInfo 元数据映射到包含版本的 ExternalScriptInfo 成员似乎是合理的。

史蒂夫的这个假设要小心。 我可能有一个具有多种功能的 ps1 文件。 我不想相信 Get-Command 可以找到脚本文件。 哎呀，我可能想在 PowerShell 配置文件脚本中定义一个版本化的函数。

在我的配置文件脚本中肯定有版本化的功能。

我们已经有了 System.Management.Automation.FunctionInfo 类型，它有一个 Version 属性。 我们需要一种方法，以便在加载函数时，从函数中的元数据填充版本属性。

感谢大家的反馈！ 我还有一些问题。 如果 PowerShell 发现一些具有相同名称的函数，您期望什么行为？ 运行更高版本的功能？ 我们是否应该考虑范围（您在当前范围内加载旧函数 - 我们是否应该从全局范围调用更多新函数）？ 或者我们只想拥有信息属性？

这与运行或分发功能无关。 我想要的是一种机制来提供一种跟踪和发现版本信息的方法，这样如果我运行 Get-Command，或者可能是像 Get-Function 这样的新命令，我就可以看到有关该函数的一些元数据。 我有一些想法可以尝试通过 PowerShell 脚本进行原型设计。

感谢大家的反馈！ 我还有一些问题。 如果 PowerShell 发现一些具有相同名称的函数，您期望什么行为？ 运行更高版本的功能？ 我们是否应该考虑范围（您在当前范围内加载旧函数 - 我们是否应该从全局范围调用更多新函数）？ 或者我们只想拥有信息属性？

我认为没有人建议改变 PS 执行功能的方式。 我们只是想为它们添加一个版本。 信息和一种询问方式。

谢谢！ 我有下一个问题。 具有某些功能的文件可能具有文件中所有功能通用的版本属性。 我们应该考虑这个吗？

我有一些想法可以尝试通过 PowerShell 脚本进行原型设计。

您可以分享要点中的想法。

这就是我的计划。

它应该是经典版还是 SymVer 2.0？

我越来越相信函数版本控制是一件好事。

回答@iSazonov最新问题 - 如果我们要拥有它，为什么不使用 SymVer？

关于函数文件 - 我认为该属性是每个函数的，没有每个文件的属性。 很像今天的 CMDLETBinding 工作。

原型被拉入 ##11686

您可以从 PR 下载工件并使用新属性进行游戏。

甜的。

考虑一下 - 为什么不扩展 PSVersionAttribute 以包含脚本的版本。 如果我们版本模块和（希望现在！）函数，为什么不脚本？

PSVersionAttribute 还可以用作脚本中定义的函数的默认值。

在其他人问之前......函数执行可以版本化吗？

我们可以加载一个函数的多个版本，默认情况下执行最新的版本，但有一个 -PSFunctionVersion 公共参数，用于说明要运行的特定版本。
毫无疑问，还有更多的选择——但我们应该提供版本化的函数执行吗？

如果它是一个属性，您可以随时重用它，就像[CmdletBinding()]可以同时应用于函数和脚本一样，您始终可以将[PSVersion()]用于函数和脚本。 这看起来是一种有趣的方法。 🙂

我不认为在模块中大量使用这种东西，我们已经在大多数情况下使用了版本化代码，但是对于独立的脚本和函数，这确实非常有趣🙂

这与运行或分发功能无关。 我想要的是一种机制来提供一种跟踪和发现版本信息的方法，这样如果我运行 Get-Command，或者可能是像 Get-Function 这样的新命令，我就可以看到有关该函数的一些元数据。 我有一些想法可以尝试通过 PowerShell 脚本进行原型设计。

如果我们要添加功能版本控制，为什么要将其限制为纯文档？ 如果我可以指定和查询函数版本，允许基于版本号执行不是明智的吗？

一种方法是加载一个函数的多个版本并能够选择一个来执行，或者使用户能够在不同的版本中进行选择以加载到我们用 gcm 看到的函数列表中，然后执行那个。

所以这是我基于 ScriptFileInfo 命令进行的概念验证：
https://gist.github.com/jdhitsolutions/65070cd51b5cfb572bc6375f67bcbc3d

我真正想要建模或原型的是体验。 我宁愿使用 Get-Command 公开数据，因为已经有合适的类型。

并获得混合文件。

如果一个函数属于一个模块，我不会打扰命令版本控制。 这应该由模块处理。

要旨

添加和获取 PowerShell 元数据信息的概念证明

添加和获取 PowerShell 元数据信息的概念证明 - PSFunctionInfo.format.ps1xml

杰夫好！

那么我们如何处理同一个函数的多个版本呢？
如何显式加载特定的函数版本？
如何显式执行特定版本的函数？

@doctordns您负责确定要运行的内容并处理多个版本。 我的原型代码只是列出 Function: Psdrive 中的项目并显示元数据信息。 据我所知，psdrive 中不能有重复的功能。 我的目标是，如果我加载了一个独立的函数，我希望能够检索版本和其他可能的元数据信息。

虽然我认为如果 PowerShell 支持 _scripts_ 的 _embedded_ PSScriptInfo 元数据会很棒……请不要在 _function_ 级别这样做。

版本只有在您可以对它们做些什么时才有用

PowerShell 当前_reports_ 命令的版本，但实际版本来自_module_。 为每个功能设置单独的版本不会有帮助，只会令人困惑。 无论您如何分发代码，您都不会分发子文件“大块头”，并且用户无法加载单个函数（或除完整文件之外的任何内容）——因此尝试对它们进行版本控制毫无意义。

我认为我们需要模块和脚本的版本。 函数应该从包含它们的 _module_ 继承它们的版本。 脚本需要自己的版本。

作为记录：

如果您有一个包含多种功能的 .ps1 文件，则需要更改扩展名。 如果不这样做，那么用户无论如何都无法发现这些功能，因此版本控制无关紧要。 我们应该积极阻止任何试图在模块以外的任何东西中分发 _functions_ 的人。 🤨

@Jaykul我同意如果一个函数附带一个模块，这应该是目标，模块版本很重要。 但是，有许多使用独立功能的用户。 也许加载在配置文件或点源中以满足特定需求。 并非我所做的一切都需要加载并构建到模块中。 我要管理的正是这些非模块功能。 我想要一种方法来捕获版本和其他元数据信息，就像我们对从模块加载的命令所做的那样。 也许答案是像我的原型一样的新命令。

@Jaykul我认为我们中的一些人已经说过它确实对我们有用，并且我们确实在分发单个功能。

IMO，并非所有东西都需要一个模块。

建议的功能可能对您没有用。 这很好。 但这对我们其他人来说。

我喜欢函数版本控制的想法。 但是如果我们做一个解决方案，它应该不仅仅是一个你可以在评论中做的小文档 没有能力控制不同版本的加载等等，这是我们现在可能不需要的功能。

我建议我们在 7.0 中放弃这个想法。 我们离 RTM 太近了，无法将新功能融入其中。 我对 NT 5 天有不好的回忆！！ 如果我们可以将其推回到 7.1，那么让我们就如何全面实施它进行更全面的讨论。 试图在最后一刻推出它肯定会导致失望。

如果发生这种情况，则是 7.1 添加。 我认为加载正确版本的问题取决于用户。 同样，我所要求的只是一种从加载的独立函数中检索版本信息而无需挖掘源代码的方法。

我同意 7.1。

同时，我了解用户，我敢打赌，文档解决方案只会生成对基于版本的运行时功能的请求。 我希望我们考虑一个完整、优雅且精心设计的解决方案。 .

我们已经有一个独立功能的解决方案 - 最后一个加载获胜。 :-)

如果无法控制不同版本的加载等，这是我们现在可能无法实现的功能。

这将迫使我们在每次调用时检查函数的版本。 出于性能原因，这是完全不可接受的。 模块是最好的折衷方案——在模块加载时进行一次版本检查。

@SteveL-MSFT 我相信它已经为 PowerShell 委员会的结论做好了准备。 原型#11686。

似乎所有人都同意脚本版本在引擎中很有用。
函数的版本存在问题，因为存在模块概念。

常见的限制是我们只能看到加载的脚本和函数的版本，不能像 import-module 那样做——加载需要的版本但 get-module 也没有明确的版本参数。

不要想太多，也不要让它变得比需要的更复杂。 模块附带的功能属于模块。 句号。 这应该是推荐的最佳实践。 但是，并非每个可能在生产中使用的功能都与模块一起部署。 我实际上并不关心它是如何部署的。 我想说的是，我想要一种方法来查看 Function: PSDrive 中加载的函数，并且能够看到版本号，也许还有其他一些元数据信息。 我不想强迫自己或最终用户追踪源代码或文件夹以发现版本信息。

我希望 Get-Command 是收集这些信息的工具，但也许需要将其拆分为完全独立的独立功能管理工具。

也许答案是这个问题最好留给社区来解决。 在这种情况下，我认为我在解决方案上有一个良好的开端。

老实说，点源函数不是正确的方法，而且在模块系统出现在 v2 中的那些年里不应该被推荐。 它唯一可以远程使用的时间是在 v1.1 中。

众所周知，所有函数实际上都应该放在一个模块中，即使是那些作为配置文件的一部分加载的函数（你应该加载包含这些函数的模块）或用作更大脚本的一部分以便于维护，甚至那些需要在 xyz 脚本中使用的奇异函数。

我只能看到，通过将建议的[Version]属性添加到函数定义中，这种更改会给使用该语言的人带来更多的混乱，许多人认为他们在执行时需要设置模块和函数版本事情正确并实际构建可重用代码的模块。

是的，这意味着你必须有一个 psd1 和一个 psm1，但是 2 个文件对于正确的可发现性和可维护性并不是一个真正管理的巨大要求

正如你可能会说的，我个人不同意这种变化，并认为有更好的事情需要关注

是的，这意味着你必须有一个 psd1 和一个 psm1，但是 2 个文件对于正确的可发现性和可维护性并不是一个真正管理的巨大要求

是的，这是一个很大的问题。 试图让管理员脚本编写人员成为开发人员会显着提高进入门槛。

说“哦，你必须在这里复制这个，然后在那里复制然后导入”比说“复制并粘贴到一个名为 run.ps1 的文件中，然后输入 ,\run”要复杂得多，而且更容易出错.ps1”。

这是一个小改动，它对临时/管理员脚本编写者的好处远远超过三元运算符或空合并（我仍然不明白）或许多其他最近为开发人员所做的更改。 就像那些说的那样，我可以说一下函数版本：如果你不喜欢它，就不要使用它。

@SteveL-MSFT 我相信 PowerShell 委员会可以查看支持脚本和独立功能版本的请求。 原型在#11686 中。

老实说，点源函数不是正确的方法，

但是人们会这样做，而且无论如何它都不是此请求的唯一用例。

并且不应该在模块系统出现在 v2 中的那些年里被推荐。 它唯一可以远程使用的时间是在 v1.1 中。

众所周知，所有函数实际上都应该放在一个模块中，即使是那些作为配置文件的一部分加载的函数（你应该加载包含这些函数的模块）或用作更大脚本的一部分以便于维护，甚至那些需要在 xyz 脚本中使用的奇异函数。

我只能看到，通过将建议的[Version]属性添加到函数定义中，这种更改会给使用该语言的人带来更多的混乱，许多人认为他们在执行时需要设置模块和函数版本事情正确并实际构建可重用代码的模块。

是的，这意味着你必须有一个 psd1 和一个 psm1，但是 2 个文件对于正确的可发现性和可维护性并不是一个真正管理的巨大要求

是的，但这无关紧要。 没有人会争辩说我们不应该对模块进行版本控制。 ;-)

正如你可能会说的，我个人_不同意_这一变化，并认为有更好的事情需要关注

您不需要使用它。 您实际上也没有被迫使用 [CmdletBinding()] 或参数集。
命令和 cmdlet 都有版本。
如果函数本身有一个版本，_无论所述函数是否驻留在模块中_，它只是一个次要但有用的文档点。 我创建了许多模块，其中包含各种不相关的工具，这些工具并不能证明它们自己的单个模块的合理性。 如果我的模块是MiscStuff 1.1.0002 ，那对于分发部分来说很棒； 我用那个。 如果其中有 30 个函数，并且我想快速注意我是否在使用Do-Thing 7.9.0并且能够将它与我的变更日志中的项目相关联（我这样做了！），我想要一些正式的方法这样做，那些不希望这样做的人绝不会要求这样做。

@PowerShell/powershell-committee 对此进行了审查，我们认为对脚本函数进行版本控制的正确解决方案是将它们包装在一个模块中。 如果脚本函数在模块内，但有自己的版本属性，那么它也不清楚预期的行为是什么。 然后担心 PowerShell、PowerShellGet 和 PSGallery 的其他部分需要更新以尊重这个新属性。 如果希望能够传递单个脚本文件与文件夹（模块），那么最好投资于直接导入 zip/nupkg 模块的能力，并且更容易将 .ps1 转换为模块。

作为管理员脚本编写者而非开发人员，我认为 #7259 和此请求 (#11667) 之间没有任何关系。

作为管理员脚本编写者，我不会学习如何使用模块。 这与我无关。 它没有给我提供任何价值。 这是开发人员的开销。 模块是一个非启动器。 （不仅适用于我，而且适用于大多数管理员脚本。）

对于管理员脚本人员而不是开发人员 - 委员会如何建议对功能/过滤器进行版本控制？

不是逆势而上，而是……总的来说，版本控制本身是一个开发人员的概念。 我不知道你为什么要在所有可能的地方画这条线。 😕

因为我已经发布了几十个独立的函数和脚本。 没有模块。 可以肯定的是，我之前的评论中已经涵盖了这一点，以及其他几位受欢迎的博主/出版商。

我认为 #7259 和这个请求 (#11667) 没有任何关系。

是的，老实说，我也没有真正得到联系。

我不会学习如何使用模块。

FWIW 您只需将扩展名更改为psm1并（可选）运行New-ModuleManifest 。 它没有很多。

这与我无关。 它没有给我提供任何价值。

如果你发布一些东西供其他人消费，它肯定会提供价值。 作用域为模块工作的方式使得踩到某人的全局会话状态变得更加困难，反之亦然。 这使您的函数对环境中的意外差异更具弹性。

它也更容易消费。 如果您将函数作为脚本发布，人们需要点源，他们需要知道它在哪里，点源它，然后使用命令。 如果你将它作为一个模块发布，人们可以提前部署它并随时调用它。

委员会如何建议对功能/过滤器进行版本控制？

如果为单个功能实现了版本控制，您是否希望它们的版本是可查询的？

如果是，您能否详细说明您希望用户查询它的场景？ 您是否希望它可以在任何其他系统中播放，例如#requires标签？

如果它只是源中可见的元数据，那么您可以将它放在基于评论的帮助的NOTES部分。

根据 PowerShell 委员会的结论，我关闭了该问题（停止跟踪），但您可以继续讨论。

是的，我今天使用 NOTES 部分和 $pVersion/$pName。 我怀疑我们大多数人有需要，那就去做吧。

当我写“我不会”时，我说的是一般人，而不是具体的我（尽管我属于那个类别）。

和一个 $pVersion/$pName

你拿这些做什么？ 你有发布过的松散函数的例子吗？ 这可能有助于理解用例。

当我写“我不会”时，我说的是一般人，而不是具体的我（尽管我属于那个类别）。

是的，肯定有人拒绝学习模块。 我认识并且现在认识很多这样的人（并且几年前有人说他们），没有争论他们存在。 也就是说，这些人与那些 1. 关心版本控制和 2. 想要发布他们的作品的人之间的重叠 - 根据我的经验几乎为零。 实际上，大多数选中框 1 和框 2 的人会在发布之前花大约 10 分钟的时间在谷歌上搜索如何快速封装模块。 或者更常见的是，他们不关心版本控制，他们只会在要点或博客文章中猛烈抨击它。

和一个 $pVersion/$pName

你拿这些做什么？ 你有发布过的松散函数的例子吗？ 这可能有助于理解用例。

当我写“我不会”时，我说的是一般人，而不是具体的我（尽管我属于那个类别）。

是的，肯定有人拒绝学习模块。 我认识并且现在认识很多这样的人（并且几年前有人说他们），没有争论他们存在。 也就是说，这些人与那些 1. 关心版本控制和 2. 想要发布他们的作品的人之间的重叠 - 根据我的经验几乎为零。 实际上，大多数选中框 1 和框 2 的人会在发布之前花大约 10 分钟的时间在谷歌上搜索如何快速封装模块。 或者更常见的是，他们不关心版本控制，他们只会在要点或博客文章中猛烈抨击它。

我知道如何使用模块。 我一直在写它们。 哎呀，这些函数很多时候都在模块内部，我使用内部版本控制，这样我就可以跟踪函数中最后更改的内容，而不必拉出外部（对函数）更改日志。 我不明白为什么函数中的.VERSION会干扰模块版本。 我只是不知道。

我知道如何使用模块。 我一直在写它们。 哎呀，这些函数在很多时候是 _inside_ _modules_，我使用内部版本控制，所以我可以跟踪函数中最后更改的内容，而不必拉出到外部（对函数）更改日志。 我不明白为什么函数中的.VERSION会干扰模块版本。 我只是不知道。

是的，但最重要的是：你打算用那个元数据做什么？ 它只是您在函数源中查看的内容吗？ 如果是这样，您能否详细说明.NOTES部分不适合该部分？

此外，这个问题是为了允许独立函数在Get-Command输出中声明它的版本号。 包含完整更改日志的请求将是一个完全不同的实现，并且可能更好地解决它自己的问题。

这很容易回答。 这意味着我必须在编辑器中打开它或执行某种类型的笨拙的字符串搜索，以找出安装在给定计算机/给定位置的所述计算机上的版本。 这并不总是像这个答案一样容易。 :-)

并不真地？

如果您将其编写为基于注释的正确帮助（无论如何您都应该这样做），则注释字段会显示在 Get-Help 输出中。

function test {
    <#
    .NOTES
    Version: 1.5.0
    #>
    [CmdletBinding()]
    param()
}

Get-Help test -Full

# or
Get-Help test | % alertSet

结果：

PS> Get-Help test -Full
SYNTAX
    test [<CommonParameters>]


DESCRIPTION


PARAMETERS
    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer, PipelineVariable, and OutVariable. For more information, see
        about_CommonParameters (https://go.microsoft.com/fwlink/?LinkID=113216).

INPUTS

OUTPUTS

NOTES


        Version: 1.5.1


RELATED LINKS

PS> get-help test | % alertset



    Version: 1.5.1

所以？ 我没有印象。 还有其他更详细的方法来执行三元运算符。 然而......实现了一种更紧凑的方式。 因为（一部分）社区想要它。 我仍然不知道空合并运算符到底是什么。

不太确定你在追求什么，然后。 很明显，这可以让您相对轻松地完成您想要的工作。 我认为不值得花时间在那里添加额外的字段。

如果您这样做，请随时打开 PR，我们将进一步讨论。 🤷

公关干什么？ 我不是 C# 编码员。 我已经 30 多年没有成为专业的开发人员了。

我认为我们中的一些人非常清楚我们的目标是什么，我们的用例，并且看到这些担忧被最小化，就像你刚刚再次做的那样。

那些超越管理脚本的人认为“只是让它成为一个模块”。 大多数管理员脚本编写者不知道如何做，他们会说（我同意）一旦他们看到要求就太麻烦了。

但这毫无意义，我知道得更好。 PowerShell 委员会的结论已经达成。 抱歉我评论了。

PowerShell 委员会的结论已经达成。

可以根据反馈重新考虑任何设计结论。

我认为我们中的一些人非常清楚我们的目标是什么，我们的用例，并且看到这些担忧被最小化，就像你刚刚再次做的那样。

我一直在努力弄清楚实际目标和用例是什么，但我的问题大多被忽略了。 我真的很想了解。

那些超越管理脚本的人

伙计，我是系统管理员。 我职业生涯的大部分时间都花在认为哈希表语法是“splatting 语法”上。 我的大多数同事只知道 PowerShell 的绝对基础（如果有的话），与我在 discord/reddit 上帮助的大多数人一样。

我知道你对 PS 开发团队有些不满，但请不要假装我不可能理解你的观点，因为我现在碰巧知道 C#。 我一直在为这个 repo 的观点而奋斗。

认为“只是让它成为一个模块”。 大多数管理员脚本编写者不知道如何做，他们会说（我同意）一旦他们看到要求就太麻烦了。

对于稍后遇到此线程并不鼓励制作模块的任何人，以下是要求：

1. 将您的.ps1文件重命名为.psm1
2. 使用Import-Module ./file.psm1而不是. ./file.ps1

就是这样，你有一个模块。 其他一切都只是您不需要担心的最佳实践。 如果要对其进行版本控制，则需要一个清单，以下是其完整要求：

1. 将您的.ps1文件重命名为.psm1
2. 运行New-ModuleManifest -RootModule ./file.psm1 -Path ./file.psd1 -ModuleVersion 1.0.0
3. 使用Import-Module ./file.psd1而不是. ./file.ps1

如果您要在 ps1 中提供消费者（或您自己）需要点源的松散功能，只需将其快速放入模块中，它会让您的生活更轻松。

如果您要发送一个可直接调用的脚本，您可以使用New-ScriptFileInfo来生成一个带有如下注释的脚本文件：

<#PSScriptInfo

.VERSION 1.0.0

.GUID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

.AUTHOR username

.COMPANYNAME

.COPYRIGHT

.TAGS

.LICENSEURI

.PROJECTURI

.ICONURI

.EXTERNALMODULEDEPENDENCIES 

.REQUIREDSCRIPTS

.EXTERNALSCRIPTDEPENDENCIES

.RELEASENOTES


.PRIVATEDATA

#>

<# 
.DESCRIPTION 
     Quick script description here.
#> 
param()

你可以用Test-ScriptFileInfo 。