问COM & CoGetClassObject()

EN

与CoCreateInstance()相比，CoGetClassObject()只完成一半的工作。它返回一个类工厂。CoCreateInstance()然后调用IClassFactory::CreateInstance()并释放IClassFactory。只有当您需要创建某个coclass的许多对象并希望对其进行优化时，才会使用它。它避免了一次又一次创建和发布工厂的成本。

您可能忽略了这个问题的一个简单得多的解决方案。只需将新版本的COM服务器DLL复制到与客户端EXE相同的目录中即可。并创建一个名为"app.exe.local“的零字节文件，其中"app”是EXE的名称。这足以强制加载复制DLL，而不是注册表所指向的DLL。MSDN Library关于DLL重定向is here的文章。

非常简单的解释是，CoGetClassObject()打开HKCR\CLSID\{ClassId}并查看InProcServer32或LocalServer32，这取决于传递的CLSCTX_*值-即COM服务器路径。

一旦找到COM服务器文件路径就加载到COM服务器(进程内使用LOAD_WITH_ALTERED_SEARCH_PATH标志的LoadLibraryEx()，进程外使用CreateProcess() )。然后，它定位并调用进程内服务器的DllGetClassObject()，或者等待，直到为进程外服务器注册了类工厂。

当然，这会忽略DCOM等内容。您可以使用进程监视器工具更好地了解它是如何遍历注册表的。

如果您希望加载特定的COM，而不管是否安装了较新的版本，也不管较旧的DLL位于何处，则只需完全忽略CoCreateInstance()和CoGetClassObject()。通过LoadLibrary()自己加载旧的动态链接库，然后直接调用其导出的DllGetClassObject()函数来获取动态链接库的IClassFactory接口，然后根据需要调用IClassFactory::CreateInstance()。这是CoCreateInstance()和CoGetClassObject()在内部执行的所有操作，但这绕过了它们执行的注册表查找，以确定要加载的DLL路径。