Powershell中不一致的程序集加载行为答案

【问题标题】：Inconsistent assembly loading behavior in powershellPowershell中不一致的程序集加载行为
【发布时间】：2014-12-02 23:13:56
【问题描述】：

我正在调试为什么一个 powershell 脚本开始失败，并且它看起来像是在使用 Hashset 而不引用 System.Core 程序集，所以修复结果是这样的：

Add-Type -AssemblyName System.Core
$hash = new-object 'System.Collections.Generic.HashSet[string]'

我不知道它以前是如何工作的，并且在某些机器上仍然运行良好，没有添加类型行。我在这里错过了什么？

【问题讨论】：

检查 $profile 看看它是否在那些机器上加载了该程序集？
不同的 PowerShell 版本？
@NathanTuggy 我仔细检查了，两台机器上都没有配置文件。
@ojk 两台机器上的 powershell 版本相同。
我的猜测是该程序集先前已由您另一台计算机上的另一个应用程序加载。在两者上尝试 [appdomain]::currentdomain.GetAssemblies() 并查看 System.Core 是否已加载。

标签： powershell powershell-2.0

【解决方案1】：

继续 David 的想法，并且由于 cmets 中的代码很糟糕，您应该检查程序集是否已加载。一个关于检查程序集的小博客是here

If (!(([appdomain]::currentdomain.GetAssemblies()).FullName -match "System\.Core")){
    Add-Type -AssemblyName System.Core
}
$hash = new-object 'System.Collections.Generic.HashSet[string]'

我默认加载了这个程序集。好奇受影响的系统有什么。受影响机器上的 Dot.Net 框架版本是什么？在 Windows 更新后，我的一些 3.5 代码停止工作，需要重新安装框架。

来自Jeroen Mostert的评论

如果您想真正准确地了解它，您应该确认您已经得到了 .NET 自己的 System.Core，而不是任何老冒名顶替者，然后无需检查是否已经发生。 Add-Type -AssemblyName "System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"

【讨论】：

好吧，如果你想非常精确，你应该验证你有 .NET 自己的System.Core，而不是任何旧的冒名顶替者，然后有无需检查是否已经发生。 Add-Type -AssemblyName "System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" 本身就足够了（如果需要，版本策略将负责加载更高版本）。
@JeroenMostert 好计划。我的看起来像这样System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 不确定操作需要哪一个。谢谢。我仍然不确定是否应该删除它。
因为HashSet 存在于 3.5 中，所以我会使用它来最大限度地提高脚本运行的机会。当然，除非你特别需要 .NET 4.0，但那不是因为HashSet。
问题将是，如果默认环境已经加载了System.Core, Version=4.0.0.0, ...——如果你有 PowerShell 4.0，则程序集应该自动加载，AFAIK——然后Add-Type 将失败：@ 987654322@（见-Name参数）
@BaconBits：但事实并非如此。我在自己的系统上尝试过，当尝试加载System.Core 的 3.5 版时，Add-Type 完全没有失败，因为 4.0 版已经加载（Powershell 3.0）。这是有道理的，因为在 .NET 4.0 上请求 3.5 只会得到 4.0，这取决于版本控制策略。