PowerShell中New-Object与[type]::New()的SignedXml构造差异问题

这个问题我之前也碰到过，确实挺让人困惑的——明明同一个构造逻辑在ISE里好好的，放到独立脚本里就报错，核心原因其实是PowerShell的程序集加载机制在不同环境下的差异，下面给你拆解清楚：

核心原理：程序集加载时机的差异 #

• New-Object的自动加载特性：当你使用New-Object system.security.cryptography.xml.signedXml -argumentList:$xml时，PowerShell的New-Object cmdlet会自动解析目标类型的全名，找到它所在的.NET程序集（这里是System.Security.dll），并将该程序集加载到当前会话中，之后再创建对象。这个过程是自动完成的，不需要你手动干预。
• 静态构造器::New()的依赖前提：直接调用[System.Security.Cryptography.Xml.SignedXml]::New($xml)时，PowerShell要求这个类型已经被加载到当前会话的程序集列表中。而ISE在启动时，可能因为自身的功能依赖（比如内置的XML安全处理逻辑）已经提前加载了System.Security.dll，所以在ISE环境下运行没问题；但独立脚本执行时，会话是全新的，这个程序集还没被加载，就会抛出“无法找到类型”的错误。

如何预判这类问题？ #

• 识别非核心.NET类型：对于.NET Framework中不属于默认预加载的类型（比如加密、XML安全、特定系统组件相关的类型），直接使用类型名（包括调用静态方法、构造器）前，一定要确认其所在的程序集是否已经被加载。
• 提前验证程序集加载状态：可以在ISE中运行以下命令，查看目标类型所属的程序集：

  [System.Security.Cryptography.Xml.SignedXml].Assembly.FullName
  

  得到结果后，就可以在脚本开头提前加载该程序集。
• 养成提前加载程序集的习惯：对于非通用类型，在脚本开头显式加载其程序集，避免因环境差异导致的加载失败。

除了退回New-Object，还有更好的解决方案吗？ #

当然有，而且能保持代码的一致性和可读性：

方案1：显式加载目标程序集 #

在脚本的最开头添加以下命令，提前加载SignedXml所在的程序集：

Add-Type -AssemblyName System.Security

加载完成后，你就可以正常使用[System.Security.Cryptography.Xml.SignedXml]::New($xml)来构造对象了，无论在ISE还是独立脚本中都能正常运行。

方案2：间接获取类型并构造对象（不推荐，仅作备选） #

如果不想显式加载程序集，也可以通过Type.GetType()方法间接获取类型，再调用构造器，但这种写法不如显式加载直观：

$type = [Type]::GetType("System.Security.Cryptography.Xml.SignedXml, System.Security, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$signedXml = $type::New($xml)

不过这种写法需要你知道类型的完整程序集限定名，不如Add-Type方便。

总结 #

New-Object和::New()的差异本质是程序集加载时机的问题，只要提前显式加载目标类型所在的程序集，就能统一使用::New()的写法，保持代码风格一致。不需要每次都退回New-Object，只需要在脚本开头加一行加载程序集的命令即可。

内容的提问来源于stack exchange，提问作者Gordon