Type.GetTypeFromProgID调用Win10正常Windows Server2019返回null问题排查

相关代码片段 #

private bool StartSkript(string Systemskript)
{
    Type typeFromProgID = Type.GetTypeFromProgID("xxx.application"); // 该行在Windows 10上运行正常，在Windows Server 2019上运行时返回null
    if (typeFromProgID == null)
    {
        return false;
    }
    try
    {
        dynamic applicationInstance = Activator.CreateInstance(typeFromProgID);
        applicationInstance.RunFormSkript(Systemskript, 0);
        return true;
    }
    catch (Exception)
    {
        return false;
    }
}

问题1：为什么检索的是xxx.application而非进程名xxx.exe？ #

你当前使用的是**COM自动化（OLE自动化）**的跨进程调用方案，Type.GetTypeFromProgID的入参是COM组件的程序标识符（ProgID），这是COM架构下约定的对象标识规则，和进程名没有直接关联：

• ProgID是COM组件开发阶段预先定义的字符串标识，用于映射注册表中对应的COM类ID（CLSID），最终定位到COM对象的实现逻辑
• 你要调用的RunFormSkript是xxx应用暴露的COM接口方法，所以只需要通过ProgID就能创建对象调用接口，不需要手动根据进程名挂载到目标进程

问题2：Server 2019环境下的排查方案 #

返回null的核心原因是系统找不到xxx.application对应的COM注册信息，按以下步骤排查即可：

步骤1：检查ProgID注册状态 #

打开注册表编辑器，优先检查以下两个路径是否存在xxx.application子项：

• 64位COM组件/64位程序：HKEY_CLASSES_ROOT\xxx.application
• 32位COM组件/32位程序跑在64位系统下：HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\xxx.application
  如果子项不存在，说明xxx应用没有在当前系统正确注册COM接口，可以重新安装xxx应用，或者手动执行xxx应用的COM注册命令。

步骤2：校验位数匹配 #

如果你的C#程序编译时指定了固定的x86/x64架构，需要和xxx应用的编译架构完全一致，位数不匹配的情况下即使ProgID存在也会返回null，可在项目生成设置里调整目标平台。

步骤3：快速验证ProgID有效性 #

在目标Server 2019机器上，以程序运行的用户身份执行PowerShell命令：
New-Object -ComObject xxx.application
如果执行报错提示找不到COM对象，说明ProgID无效、未注册或者位数不匹配；如果执行成功能拿到对象实例，说明是C#程序的配置问题，可检查项目是否开启了COM互操作权限。

步骤4：检查COM权限配置 #

打开系统组件服务（运行dcomcnfg），找到xxx.application对应的COM对象，检查「启动和激活权限」、「访问权限」是否已经给了当前程序运行的用户，Windows Server默认的安全限制比Windows 10严格，容易出现权限不足的问题。

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