DCOM 服务器和客户端都用 .NET 编写

Posted 2023-02-22

【中文标题】DCOM 服务器和客户端都用 .NET 编写

【英文标题】：DCOM server and client both written in .NET

【发布时间】：2011-07-01 21:52:44

【问题描述】：

我正在使用 .NET 4（VS2010，C#）开发 DCOM 服务器。就其本身而言，它运行良好。

现在，我还需要为此 DCOM 服务器开发一个 .NET 客户端，但我无法添加对 TypeLib 的引用。 Visual Studio 会告诉我类型库是从 .NET 程序集中导出的，不能作为引用添加。

对this question 的回答表明我应该能够使用TlbImp.exe 来生成包装程序集，但它也会拒绝这样做：

TlbImp：错误 TI1029：类型库 “MyWrapper”是从 CLR 导出的 程序集，不能重新导入为 一个 CLR 程序集。

我理解，从纯粹的 .NET 角度来看，为此使用 DCOM 可能没有多大意义。但是，非 .NET 应用程序也应该可以访问同一服务器。

我尝试将我的 tlb 转换为 IDL 并从中重新生成 tlb，但这并不能欺骗 Visual Studio。

也许可以在重新生成之前稍微修改 IDL，或者有什么方法可以强制使用 DCOM，即使服务器和客户端都是用 .NET 编写的？

【问题讨论】：

你为什么不想创建一个纯 .Net 引用？如果你将你的类库导出到 COM，它不会禁止你在 .Net 中使用它。

如果您想要远程托管，我会直接在 .NET 或 WCF 中引用程序集。然后创建一个 c# 代理，将其导出为可以从旧客户端引用的普通 COM 对象。这样，当非 .NET 应用程序最终消亡（假设这是您的长期目标）时，您就有了一条清晰的切断路径。

【参考方案1】：

我设法让 DCOM 工作，但我不确定它是否可以从 TypeLib 中完成。修改 IDL 允许我导入类型库，但它最终在编译期间失败（尽管这被 Visual Studio 视为警告）。可能仍然可以对文件进行更多修改，但我使用的是更简单的解决方案。

DCOM 服务器的所有接口定义都已移至单独的程序集，然后直接从 .NET 客户端引用。这绕过了导入问题。

那么，访问 DCOM 服务器与预期的没有什么不同：

Guid clsId = new Guid("XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX");
Type type = Type.GetTypeFromCLSID(clsId);
IMyInterface comObject = (IMyInterface)Activator.CreateInstance(type);

将接口移动到单独的程序集并不是绝对必要的，但这可以最大限度地减少共享程序集的大小。

【讨论】：

这很好用，只要记住在重新编译时保持界面二进制文件与正在运行的版本兼容

我不太确定...您可以在此处使用 Guid 创建对象，但我认为它们不遵循实际的 COM 创建过程。由于两者都是托管的，CLR 只是绕过整个 COM 恶作剧并返回一个普通的旧 C# 对象。见这里：***.com/questions/15014266/…