COM+由 C# 中的 Windows 服务托管的组件，用于控制外部设备
我有一个用 C# 编写的 Windows 服务，它控制通过 RS232 连接到计算机的设备（收集数据并允许控制设备）。它名为 DeviceService 并且工作正常。现在其他应用程序通过 WCF 服务使用它。
但现在我需要将一些功能公开为 COM+ 组件，以便 C++ 中的应用程序可以与此 Windows 服务进行通信（并从中获取实时数据）。
（我知道可能有更好的方法来做到这一点，但这是无法更改的要求。它必须通过 COM+）。
问题是：当我在 DeviceService 中创建这样的组件并在客户端上激活它时，它看不到任何数据。例如：Windows 服务 (DeviceService) 中的静态变量对于在同一程序集中定义的组件返回 null。就像这是另一个实例/上下文。
在 Windows 服务中托管 COM+ 组件的正确方法是什么？因此它们共享相同的上下文（静态变量）。
I have a Windows Service written in C# that controls a device connected to the computer by RS232 (gathers data and allows to control the device). It's named DeviceService and it's working properly. Now other applications use it by WCF services.
But now I need to expose some of functionalities as COM+ Component, so applications in C++ can communicate with this windows service (and get real-time data from it).
(I know that there might be better ways to do this but that's the requirement that can't be changed. It must be via COM+).
The problem is: when I create such a component in the DeviceService and activate it on the client it sees no data. For instance: static variables in Windows Service (DeviceService) return null for the component that is defined in the same assembly. Like it was another instance / context.
What is the proper way to host a COM+ component inside a windows service? So they share the same context (static variables).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正确的方法是将 COM+ 组件放入组件服务中并将其标记为多线程。所有实例将共享相同的静态变量。
The correct way to do this is to put the COM+ component in Component Services and mark it as Multi-Threaded. All instances will share the same static variables.
快速浏览 ".NET 和 COM: 完整互操作性指南"（基于 .NET 1，但 COM 互操作性没有太大变化） via Safari Books Online 不会透露任何内容。
因此，我会考虑使用 WCF 创建服务部分，然后创建一个在本地公开 COM 接口的客户端库。 （因此，用 COM -> .NET CCR 替换 DCOM 和 COM+ 的进程内 COM 代理，然后在纯 .NET 中执行其他所有操作。）
客户端库的 COM 接口当然可以在组件服务中注册，以被视为COM+（但除非您提供的功能需要某些 COM+ 服务，否则这不会实现太多目标）。
A quick glance through the contents of ".NET and COM: The Complete Interoperability Guide" (which is based on .NET 1, but COM interop hasn't changed much) via Safari Books Online doesn't reveal anything.
Therefore I would consider creating the service part with WCF, and then create a client library that exposes a COM interface locally. (So replacing the in-process COM proxy of DCOM and COM+ with a COM -> .NET CCR and then doing everything else in pure .NET.)
The client library's COM interface can of course be registered in component services to be seen as COM+ (but unless the functionality you are providing needs some COM+ service this doesn't achieve much).