为什么接口上的“添加 IDL 方法”会将方法添加到模块和 CoClass？

问题描述

这个问题是关于使用 Visual Studio 2019 构建使用 ATL 的进程外 COM 服务器。 （我之前在 Borland 做过这个，但这是我第一次使用 MSVC）。

我使用 ATL 项目向导创建了一个名为 MyObjectsProject 的项目。这在文件 class CMyObjectsProjectModule : public ATL::CAtlExeModuleT<CMyObjectsProjectModule> 中创建了模块 MyObjectsProject.cpp。

然后我通过“添加 > ATL 简单对象”添加了一个简单的对象 MyObject，如 the documentation 中所述。这创建了包含接口 MyObject.cpp 和 CoClass MyObject.h 的文件 IMyObject 和 CMyObject。到目前为止一切顺利。

我转到类视图中的 IMyObject，然后右键单击“添加 > 方法”并为其提供一些详细信息，然后将方法声明添加到 CMyObject 中的 MyObject.h 和MyObject.cpp 作为 CMyObject::method_name() 的空定义。到目前为止，一切都很好（再次）。

但同时，它在MyObjectsProject.cpp中添加了方法声明和定义作为CMyObjectsProjectModule的类成员。此外：

• 永远不会调用 CMyObjectsProjectModule::method_name() 版本 -- 当我通过客户端使用 COM 服务器并在 IMyObject::method_name() 的实例上调用 MyObject 时，它执行定义为 {{ 1}} 符合预期。
• 我可以从 CMyObject::method_name() 中删除方法声明和定义，并且没有错误。

如果添加属性，也会发生同样的事情。此外，“正在完成操作...”大约需要 45-50 秒才能运行。

---

我的问题是：将方法添加到 Module 和 CoClass 背后的原因是什么，何时会调用该版本的方法？ （或者这只是一个错误，根本不应该将其添加到模块中？）

在 Borland IDE 中，类似的功能不会向模块添加方法。

---

编辑： 最初发布的问题与名为 CMyObjectsProjectModule 的项目有关，但问题仅在项目名为 MyProject 时发生。我最初在问题中使用了与我观察到的问题不同的名称，但现在编辑了问题并使用问题中的确切名称进行了复制。

解决方法

该方法不应该被添加到Module中，并且应该不会花费45-50秒的时间来添加该方法。

每当 CoClass 名称是模块名称的初始子字符串时，问题似乎就会发生。

例如，它出现在模块为 CMyObject 的 CMyObjectsProjectModule 中，但不会出现在模块为 CMyObject 的 CMyProjectModule 中。

出现问题时，CMyObject > Derived Types > 的类视图会显示派生类型 CMyObject 和 CMyObjectsProjectModule。

我猜这是“推导出”两种类型之间的派生类型关系，其中一种是另一种的初始子字符串；此外，“添加方法”的行为决定将方法添加到它认为是添加了该方法的 CoClass 的派生类型的所有内容中。

---

结论：这似乎是 IDE 中的一个错误（或者至少是有问题的设计）；为了解决这个问题，您可以将模块重命名为以一些唯一的子字符串开头，这样所有的 CoClass 都不会与模块的初始子字符串重合。

类设计器工具没有将这两种类型显示为派生的（即该工具似乎没有使用与类视图窗口相同的启发式方法来确定一种类型是否从另一种派生)