DCOM 服务器和客户端均用 .NET 编写
我正在.NET 4(VS2010,C#)中开发DCOM服务器。就其本身而言,这工作得很好。
现在,我还需要为此 DCOM 服务器开发一个 .NET 客户端,但我无法添加对 TypeLib 的引用。 Visual Studio 会告诉我类型库是从 .NET 程序集导出的,无法添加为引用。
这个问题的答案表明我应该能够使用 TlbImp.exe
生成包装器程序集,但它也会拒绝这样做:
TlbImp:错误 TI1029:类型库 “MyWrapper”是从 CLR 导出的 组装并且不能重新导入为 一个 CLR 程序集。
我知道,从纯粹的 .NET 角度来看,为此使用 DCOM 可能没有多大意义。但是,同一服务器也应该可以从非 .NET 应用程序访问。
我尝试将 tlb 转换为 IDL 并从中重新生成 tlb,但这并不能欺骗 Visual Studio。
也许可以在重新生成之前稍微修改 IDL,或者是否有某种方法强制使用 DCOM,即使服务器和客户端都是用 .NET 编写的?
I'm developing a DCOM server in .NET 4 (VS2010, C#). By itself, this is working fine.
Now, I also need to develop a .NET client for this DCOM server, but I am unable to add a reference to the TypeLib. Visual Studio will tell me the type library was exported from a .NET assembly and cannot be added as a reference.
Answers to this question suggests that I should be able to use TlbImp.exe
to generate a wrapper assembly, but it will refuse to do so as well:
TlbImp : error TI1029 : Type library
'MyWrapper' was exported from a CLR
assembly and cannot be re-imported as
a CLR assembly.
I understand that from a purely .NET perspective, it may not make a lot of sense to use DCOM for this. However, the same server should also be accessible from non .NET applications.
I have tried converting my tlb to IDL and regenerating the tlb from that, but this does not fool Visual Studio.
Perhaps it is possible to modify the IDL slightly before regenerating, or is there some way to force the use of DCOM, even though both server and client are written in .NET?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我设法让 DCOM 工作,但我不确定它是否可以从 TypeLib 完成。修改IDL允许我导入类型库,但最终在编译过程中失败了(尽管这被Visual Studio视为警告)。仍然可以对文件进行更多修改,但我使用的是更简单的解决方案。
DCOM 服务器的所有接口定义都移至单独的程序集,然后直接从 .NET 客户端引用。这避免了导入问题。
然后,访问 DCOM 服务器与人们所期望的没有什么不同:
将接口移动到单独的程序集并不是绝对必要的,但这可以最大限度地减少共享程序集的大小。
I managed to get DCOM working, but I'm not certain if it can be done from a TypeLib. Modifying the IDL allowed me to import the type library, but it eventually failed during compilation (although this is treated as a warning by Visual Studio). It might still be possible to make even more modifications to the file, but I'm using a much easier solution.
All the interface definitions for the DCOM server were moved to a separate assembly, which is then referenced directly from the .NET client. This circumvents the importing problem.
Then, accessing the DCOM server is no different from what one might expect:
Moving the interfaces to a separate assembly is not strictly necessary, but this minimizes the size of the shared assembly.