问题摘要：我有一个启用了COM互操作/可见的C＃DLL。此C＃DLL具有对WCF服务的服务引用。当我用C＃代码实例化WCF服务时，COM互操作返回错误HRESULT（0x80131509）。
问题详细信息：
解决方案中包含三个组件。第一个是非托管的C ++应用程序。此C ++应用程序需要与WCF服务进行通信。我决定采用的方法是在C ++应用程序和WCF服务之间建立一个C＃中间层。C＃层将启用/启用COM互操作，以便C ++应用程序可以调用它，并且C＃代码将处理与WCF服务的对话。C ++方面永远不需要了解WCF服务。就其而言，COM互操作调用将是一个黑匣子。
当我尝试在C＃代码中实例化WCF服务客户端时，就会出现问题。为了方便测试，我在C＃DLL中做了一个Test（）方法。调用Test（）只会返回一个硬编码的测试字符串。这行得通。我能够启动C ++应用程序，该应用程序通过COM互操作调用C＃DLL，并返回测试字符串。HRESULT是S_OK。现在，如果我加入了改变test（）方法的单线条，简单地实例化WCF客户端时，COM互操作调用现在返回的0x80131509的HRESULT。
我唯一的线索是，当我编译C＃DLL时，会收到以下警告：
警告：类型库导出程序警告处理为“ [我的WCF服务]”。警告：类型库导出程序遇到的类型是从通用类派生的，并且未标记为[ClassInterface（ClassInterfaceType.None）]。对于此类类型，不能公开类接口。考虑使用[ClassInterface（ClassInterfaceType.None）]标记类型，并使用ComDefaultInterface属性将显式接口公开为COM的默认接口。
我不知道为什么它会警告我有关导出WCF服务类型的信息。我希望通过使用C＃中间层，可以将WCF服务与C ++应用程序隔离。
那么在COM启用/可见的DLL中使用WCF服务的窍门是什么？
经过几天的痛苦之后，找到了一个解决方案，尽管感觉比实际解决方案更像是一种变通方法。
当我意识到尝试在C＃代码中实例化WCF服务时，引发了异常，从而找到了一个线索。在C ++方面捕获了异常（确切地说是CAtlException）并查看了HRESULT代码之后，我确定C ++程序正在抱怨，因为它找不到WCF服务绑定。等一下 有点不可思议，我创建了一个.exe.config文件，并将其放在可执行文件所在的目录中。.exe.config文件基本上包含WCF服务项目中app.config的内容，此外client，该system.serviceModel节中还包含一个附加标签，其中包含endpoint指向WCF服务地址的单个标签。一切正常，一切就绪。
不过，这对我来说似乎是错误的。为什么C ++程序需要知道这一点？仅从逻辑上考虑，C＃COM互操作性应将这些知识分开并作为障碍，完全封装WCF层。通过强制C ++程序了解底层结构，它破坏了封装，并使所有内容变得更加……不明显。我完全可能不知道COM互操作的混乱内部如何工作，所以也许对某人来说这一切都是有意义的。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句