COM+ Component hosted by Windows Service in C# to control an external device

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 serv开发者_StackOverflowice? So they share the same context (static variables).

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.

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).