跨版本世界中的 PowerShell 模块

前几天我正在帮助一位朋友整理一些与模块相关的问题。在帮助他的过程中，我意识到他的问题和问题并不是独一无二的。现在我们中的许多人都在并行运行 Windows PowerShell 7，那么使用 PowerShell 模块有何影响？潜在的“陷阱”是什么？您可以采取哪些措施来减少出现问题的可能性？

PowerShell获取

Windows PowerShell 和 PowerShell 都依赖于 Find-Module 和 Install-Module 等模块命令。但是，如果您需要支持模块跨版本，则可能需要满足一个关键要求。顺便说一句，除非另有指示，否则请使用 Windows PowerShell 运行所有这些命令。

打开 Windows PowerShell 并运行

Get-Module powershellget -ListAvailable

如果您看到的唯一版本是 1.0.0.1，则需要更新该模块。 PowerShellGet 模块是您获取模块命令的地方，在跨版本世界中，您需要更高版本的模块。

然而，你不能简单地运行

Update-Module PowerShellGet

如果你这样做，你会得到一个错误。 1.0.0.1 版本是您的 Windows 10 版本附带的系统模块。它不是按照传统意义上安装的。但没问题。您仍然可以安装它。

Install-Module PowerShellGet -Force -Repository PSGallery

我安装微软版本的命令非常简洁。我们来验证一下。

Remove-Module PowerShellGet -ErrorAction Ignore
Import-Module PowerShellGet
Get-Module PowerShellGet

您应该至少看到版本 2.2.5。如果是这样，您就可以继续了。顺便说一句，既然你已经使用了Install-Module，如果有更高版本更新，你可以使用Update-Module来安装。不用担心原来的系统版本。默认情况下，PowerShell 将自动使用该模块的最新版本。

PS模块路径

难题的下一部分是一个名为 %PSModulePath% 的环境变量。此变量包含 PowerShell 和 Windows PowerShell 查找模块的所有位置。这就是模块自动加载成为可能的原因。这就是有趣的地方。

这是我在全新 Windows 10 安装上的变量。

我在“;”上分割了路径分隔符以使其更易于阅读。有 3 个默认位置。一份用于当前用户，一份用于所有用户，一份用于系统模块。在大多数情况下，我们会忽略系统路径中的任何内容。当您安装新模块时，它将进入用户路径和所有用户路径。稍后会详细介绍。

PowerShell 7.1 中也有同样的情况。

考虑系统路径的另一种方式是在 $PSHome 下。仔细看看。 PowerShell 7 还了解 Windows PowerShell 系统和所有用户位置！这意味着 PowerShell 可以“查看”Windows PowerShell 安装的模块。但是，Windows PowerShell 无法“查看”PowerShell 安装的任何内容。

安装模块

现在希望一切都清楚了，让我们安装一些模块。在 PowerShell 中，我将安装一个我知道仅适用于 PowerShell 7.x 的模块。

install-module Bluebirdps -Scope AllUsers -force

请注意 -Scope 参数。默认情况下，安装的模块是针对每个用户的。但在这种情况下，我想为所有用户安装该模块。这意味着用于安装模块的帐户需要 C:\Program Files 的管理员权限。这就是为什么默认位置是用户的位置 - 以避免需要管理员凭据。当我这样做时，我将在 PowerShell 7 中安装另一个模块。

Install-Module PSReleaseTools -force

在 Windows PowerShell 中，我将为所有用户安装一个模块，并使用默认范围安装一个模块。

Install-Module PSScriptTools -Scope AllUsers -force
Install-Module WTToolbox -force

获取安装模块

下一个问题应该是“我如何查看哪些模块可用？”。您可以使用的一个命令是 Get-InstalledModule，也是我不知道的一个命令。这是我在 PowerShell 中得到的结果。

从位置可以看出，一个模块适用于该用户，一个模块适用于所有用户。请注意，没有来自 Windows PowerShell 的模块。

Windows PowerShell 方面也是如此。

PowerShell 7 中的任何内容均不显示。但我想指出一件重要的事情。早些时候，我安装了 WTToolBox 模块，但没有指定范围。默认是用户范围，但要看位置。这就是发生的事情。我以管理员身份运行 Windows PowerShell，即在提升的会话中。在这种情况下，“用户”与“所有用户”相同。从某些方面来说，这是一件好事，因为假设兼容性的话，为所有用户安装的任何 Windows PowerShell 模块都可以在 PowerShell 7.x 中使用。

要点 #1：Get-InstalledModule 仅显示每个 PowerShell 版本安装的模块。

要点 #2：以提升用户身份安装模块始终会为所有用户安装该模块。

获取模块

那么如何“查看”哪些模块可用呢？使用获取模块。默认情况下，该模块仅显示当前加载的模块。您需要记住的关键参数是-ListAvailable。

Get-Module 搜索 PSModulePath 位置，这就是它在 PowerShell 7 中起作用的原因。要“查看”所有内容，请运行：

Get-Module -listavailable

这是一个用于清点可用模块的小代码片段。

$p = $env:PSModulePath -split ";"
 $m = Get-Module -ListAvailable
 foreach ($loc in $p) {
     [pscustomobject]@{
         Location = $loc
         Modules = ($m | where {$_.path -match $loc.replace("\","\") } ).count
     }   
 }

这是两个版本的 PowerShell 结果的组合。

要点 3：如果您需要在 Windows PowerShell 和 PowerShell 7.x 中使用某个模块，请为 Windows PowerShell 中的所有用户安装该模块。

概括

我希望这个演练能够消除任何神秘或困惑。在你走之前让我提几件事。首先，仅仅因为 PowerShell 可以“看到”Windows PowerShell 模块，并不能保证它能够正常工作。不要让这阻止你。绝大多数 Windows PowerShell 模块在 PowerShell 中都能正常工作。那些不成功的很可能会由于 .NET Core 不支持的 .NET 依赖而失败，而 .NET Core 正是 PowerShell 运行的环境。

其次，您的 PSModulePath 变量可能不同。根据您安装的应用程序或程序，您可能有其他位置。在我的主桌面上，我安装了 SQL Server Express，因此我的变量包括 C:\Program Files (x86)\Microsoft SQL Server\150\Tools\PowerShell\Modules\。

从技术上讲，您可以修改环境变量或使用配置文件脚本调整位置。如果您想包含自定义位置，则可以执行此操作。但我建议不要更新变量，以便 Windows PowerShell 可以“查看”PowerShell 模块位置。我的假设是，如果一个模块安装在 PowerShell 中，它就需要 PowerShell。例如，我在 PowerShell 中安装了 BluebirdPS 模块。如果我修改一些内容以便将其导入 Windows PowerShell，则很可能会失败。如果您需要跨版本工作的模块，请在 Windows PowerShell 中为所有用户安装它们。

我鼓励您更新 PowerShellGet，然后花几分钟阅读模块命令的帮助和示例。