PowerShell 5.1加载.NET Framework 4+程序集选Import-Module还是Add-Type

核心结论 #

针对你在Windows 10 x64 + PowerShell 5.1环境下，加载.NET Framework 4+程序集以访问类型、创建对象、调用方法的场景，优先选择Add-Type作为加载方案。

Import-Module与Add-Type的核心差异 #

二者的底层设计定位完全不同，表现出的相似加载效果只是PowerShell兼容逻辑的结果，核心差异如下：

• 设计定位不同
  • Add-Type是PowerShell专门为.NET生态交互设计的cmdlet，核心能力包括加载已有的.NET程序集、编译C#/VB等源代码生成临时程序集并加载，加载.NET程序集是它的核心官方支持场景，文档和行为稳定性有明确保障。
  • Import-Module的核心定位是加载PowerShell模块（包括.psm1脚本模块、包含PowerShell cmdlet的二进制模块），加载普通.NET程序集只是它的兜底兼容能力，不属于官方明确支持的场景，文档未覆盖该用法，后续版本行为可能发生变动。
• 加载流程不同
  • Add-Type直接调用.NET运行时的程序集加载API注入当前应用域，没有额外逻辑，加载过程轻量，加载后程序集的公共类型在整个会话全局可用。
  • Import-Module会先执行完整的PowerShell模块校验流程，包括检查模块清单、元数据、是否包含可注册的cmdlet/提供程序，确认不是标准模块后才会降级执行程序集加载，同时会将程序集类型纳入模块作用域管理体系，加载有额外开销。
• 扩展能力不同
  • Add-Type支持编译参数配置、警告忽略、内嵌代码编译等扩展能力，可满足更多自定义需求。
  • Import-Module仅支持模块相关的参数配置，无法处理代码编译等场景。

另外需要注意：.NET Framework运行时限制程序集一旦加载到应用域就无法单独卸载，因此无论使用哪种方式加载，都无法在不重启PowerShell会话的前提下卸载程序集，Remove-Module仅能将类型从当前作用域移除，不会真的卸载程序集。

Import-Module可加载普通.NET程序集的原因 #

PowerShell的模块加载逻辑做了兼容兜底：当传入.dll路径时，若校验发现该程序集不包含任何PowerShell模块相关的实现，就会自动退化为直接加载.NET程序集，并将所有公共类型导出到当前会话作用域，因此你可以正常访问程序集内的类型，该逻辑是为了提升兼容性设计的，没有写入官方文档。

Reflection.Assembly.LoadWithPartialName的作用验证 #

你的推测完全正确：该方法的设计目的就是不需要提供程序集的完整强名称和本地路径，直接从GAC（全局程序集缓存）中检索并加载匹配名称的程序集，适合快速调用系统内置的.NET Framework程序集。但该方法已被官方标记为弃用，加载的版本受系统环境影响存在不确定性，不建议在生产环境使用。

最终选型建议 #

你当前可获取程序集完整路径，优先使用Add-Type加载，标准写法为：

Add-Type -Path "C:\你的程序集完整路径\目标程序集.dll"

如果你的程序集依赖项较多，不想逐个手动加载，也可临时使用Import-Module，但需要注意该场景的兼容性风险，跨PowerShell版本（如迁移到PowerShell 7+）时需要重新验证行为。

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