COM 互操作 (CCW) 中的重载 - IDispatch 名称包括后缀（_2、_3 等）

Question

我有一个包含一些类的托管程序集，并且这些类具有重载方法。 我通过 .. 向 COM/IDispatch 调用者公开程序集，

[ComVisible(true)]

并在程序集本身上设置正确的 Guid。 我没有为 COM 互操作定义显式接口。 这一切都是动态完成的。 我在托管 DLL 上运行 regasm.exe /codebase 并将其注册为 COM 互操作。

当我运行 OleView 时，我可以看到程序集中各个类的 ProgId。 但是，浏览这些 ProgId 并展开 IDispatch 节点，会发现这些类没有 TypeLib 信息。

即便如此，我可以从脚本中调用接受零个参数的方法或接受一个参数的方法。 如果还有一个接受多个参数的重载，我无法按名称调用该方法。 我得到的错误始终是

Microsoft VBScript runtime error: Wrong number of arguments or invalid property assignment:  <methodname>

从这里我了解到 COM/IDispatch 客户端无法正确解析通过 COM 互操作公开的对象上的重载方法。

---

然后我将

[ClassInterface(ClassInterfaceType.AutoDual)]

...添加到每个有问题的课程中。 在 DLL 上的 regasm.exe 之后，我可以在 IDispatch 节点下看到每个方法的类型库信息。

我发现重载方法会自动获取包含附加后缀的名称。 MethodX 将在自动生成的 typelib 程序集中公开重载，如 MethodX、MethodX_2、MethodX_3 等。

我发现通过引用带有这些后缀的方法名称，我可以调用重载方法，尽管不是使用通用名称。

更有趣的是，如果我随后从类中删除了[ClassInterface(ClassInterfaceType.AutoDual)]，我仍然可以以这种方式调用重载方法，从而避免了>参数数量错误或属性分配无效错误。

我的问题是：这种行为 - 将数字后缀附加到成员名称 - 稳定吗？ 记录在案？ 可信？

Answer 1

COM 不支持方法重载，因此 .NET COM Interop 层必须临时改进。 我不确定您所描述的名称修改是否在任何地方都有记录，但即使是这样，我也不认为使用它是一个好主意 - 对于 COM 用户来说，它仍然是相当不方便的 API。 如果您想将类公开给 COM，最好的方法是编写一个独特的 COM 友好的 [ComVisible] 接口，并隐藏类本身。 以 COM 友好的方式处理重载的正确方法是使用带有一些 [Optional] 参数的单个方法（并委托给相应的 .NET 重载）。

Answer 2

根据我的经验，让互操作生成 Method、Method_1、Method_2 等是正常且稳定的，但并不是真正理想的。 令人烦恼的是，重载没有跨越托管/非托管边界。 我没有让它在我的方法中任意添加数字后缀，而是尝试将 COM-Visible 方法重构为具有唯一名称的单独方法，以便 COM 使用者更清楚所调用的内容。

Answer 3

的，MSDN 上有记录：

• 高级 COM 互操作性：导出成员转换

是 更改它将是记录功能的“重大更改”，我想您可以信赖它是“稳定的”。 最大的缺点是方法名称取决于它们在源文件中定义的顺序。

但请注意，COM 支持可选参数，因此使用它们可能是重载的可行替代方案。 如果您需要添加重载以与库的旧 .NET 客户端二进制兼容，我发现以下模式很有用：

// used for binary-compatibility with .NET clients who currently use 
// the old, one-parameter version
[ComVisible(false)]
void myMethod(String oneParameter) {   
    ... 
}   

// since this is the first COM-visible version, it is assigned the "correct" name.
void myMethod(String oneParameter, int newParameter = 0) {
    ...
}

由于 COM 支持可选参数，因此 myMethod(string) 和 myMethod(string, int) 会起作用。