1

I have a question about IPC with COM Interop objects. I want to create and fill with data COM Interop object in one process (for example Windows Service written in C#). Then I want to get it in another process (console application in C#). I know that COM objects don't serialize and they are unmanaged code. I tried realize solution by .Net Remoting (Windows Service is server, console application is client), but I couldn't get COM Interop object in client (I made .net class inherited from MarshalByRef in shared library, created public property with COM Interop object). Can anyone tell me, what can I do?

Zheglov
  • 61
  • 8

2 Answers2

2

You shouldn't use COM if both sides are .NET applications. It's like buying an expensive modern car, then pulling it by a horse!

First, You can use Remoting. It is easy to implement though not supported anymore and I'm advising not to use it. Anyway, remoting does not need COM Interops. Here is a simple 'Hello World' using remoting: http://msdn.microsoft.com/en-us/library/ms973864.aspx

You can also use WCF (windows Communication Foundation). This one is far more advanced and more suitable for modern applications. This is a Hello World for with WFC: http://www.codeproject.com/Articles/97204/Implementing-a-Basic-Hello-World-WCF-Service

and this one: http://blogs.msdn.com/b/jmeier/archive/2007/10/15/how-to-create-a-hello-world-wcf-service-using-visual-studio.aspx

Both technologies support IPC, TCP and HTTP

Alireza
  • 4,976
  • 1
  • 23
  • 36
  • Thank you for your time! I would gladly abandoned from COM Interop, but I can't=( I know about WCF, but it uses SOAP protocol and COM Interop is not serializable. – Zheglov Jul 13 '14 at 17:10
  • Oh I see. I apologize because should have first asked: "why do you insist on using COM?" There may be a way to do that. Let me try. – Alireza Jul 13 '14 at 18:06
  • I insist on using COM because there is old legacy program modules developed with COM Technology. These modules have many lines of code and I don't want to rewrite their. In other hand I have MS SQL Database with data necessary to fill one of the COM objects. There is WCF service which gives data from this database. And I want create some permanent entity that will fill COM Object from WCF Service and gives it to another process (for example Console App written also in C#) that will use it. Everything else I want to have only one instance of this filled COM Object (singleton). – Zheglov Jul 14 '14 at 03:58
  • That's why I don't create and fill it in Console App. Maybe it sounds incomprehensible, sorry =) – Zheglov Jul 14 '14 at 03:59
  • @Alireza, I'd disagree about the car/horse analogy, when it comes to running the server and the client app on the same PC. More thoughts [here](http://stackoverflow.com/a/24009063/1768303). – noseratio Jul 14 '14 at 04:38
  • 1
    Thanks buddy you have a good point and I liked it :) And of course my metaphor was exaggerated, I myself am still a fan of COM – Alireza Jul 14 '14 at 04:44
  • 1
    @Alireza, glad we're on the same page :) – noseratio Jul 14 '14 at 05:05
  • @Noseratio, can you give me advice?=) You have good experience with COM Interop as I see. – Zheglov Jul 14 '14 at 06:07
  • 1
    @Zheglov, I think I've already have given an advice, check [this](http://stackoverflow.com/a/22674920/1768303), [this](http://stackoverflow.com/a/24009063/1768303) and [this](http://stackoverflow.com/a/22934295/1768303). – noseratio Jul 14 '14 at 06:11
2

COM objects are not serializable as such, but when writing a COM object, you're supposed to use sophisticated proxy / stub definition - althouh in general, undercover, you don't really have to think about it, especially if these objects are written using some framework (ATL, delphi, VB6, .NET, etc.).

These proxies / stubs will at compile time or runtime use powerful RPC mechanisms (which is more or less "DCOM") if the client-server communication works out-of-process or across threads (COM "apartments" in fact).

All this to say that if your COM objects are in-process servers and were correctly built, COM provides free services to host them as "COM+ applications".

By creating logical groups of COM components as COM+ applications, you can take advantage of the following benefits of COM+: Component dynamic-link libraries (DLLs) loaded into processes (DLLHost.exe) on demand and Managed (nothing to do with .NET here) server processes to host components.

If you put your object in a COM+ Application, then you should be able to use it from .NET code just like it was in-process, but now hosted in a special "surrogate" system-provided host process (which happens to be the famous dllhost.exe). You can even configure it to become a full Windows service as shown here in the "Activation" tab of the application configuration:

enter image description here

Simon Mourier
  • 132,049
  • 21
  • 248
  • 298
  • Simon, thanks for your response! So if we choose our COM+ application used as "Server application" then we will have singleton COM Object or not? If not -- who will quite dllhost.exe process after work with object will ended? Sorry, I am noob in COM. – Zheglov Jul 14 '14 at 09:05
  • No it wouldn't be a singleton. The dllhost process recycling can be configured in the "Pooling & Recycling" tab". I suggest you create a test COM+ application and discover the numerous options in the properties dialog (like I shown). – Simon Mourier Jul 14 '14 at 09:43