There's a few different ways off the top of my head to do cross-process 
communication in .NET above and beyond what Windows provides (such as named 
pipes, RPC):


-          .NET Remoting

-          WCF

-          Raw HTTP via network loopback

Just do a .NET search and you'll see a variety of cons and pros of each.

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On 
Behalf Of Greg Keogh
Sent: Wednesday, January 15, 2014 1:40 PM
To: ozDotNet
Subject: Re: Mixing platforms

If it's managed, and no native, why not a simple recompile?

My experiment with Any CPU calling x86 was a sanity check before expanding to 
isolate some real native code. There are multiple issues at play here ...

I will soon be given a fresh Borland C++ DLL which used to be a COM server, but 
has been converted to a "plain" DLL that I'll call through Interop.

COM is great as advertised for getting wildly different components to talk to 
each other, and it's served us well for years. The reason for the change is 
twofold: (1) COM is hell to deploy and configure (2) My recent problem with 
VS2013 where it looks in the wrong registry key for CLSIDs when running as 
admin.

The second problem is so severe that I have had to move all development of one 
large project back into a VM with VS2012. There are no search hits on this 
problem and it's one of the most nonsensical and unexpected I have ever seen. I 
could spend man days experimenting with no guarantee of finding an answer or 
workaround. We decided that this was a trigger to force us to remove COM and 
use Interop.

So my experiment was to find a way of "isolating" the native Borland C++ DLL 
which has to called from an x86. Direct loading is out. Loading into an 
AppDomain is out (I quickly checked). So inter-Process is a candidate.

Managed code that spins up multiple Processes that communicate and synchronise 
is not discussed in any depth that I have found so far. Doing that with Threads 
and AppDomains is well document and quite easy, but Processes have been 
neglected. I read part of THIS 
BOOK<http://www.orthogonal.com.au/photos/Scans/Book%20Covers/Other/Win32%20Developer%27s%20Reference%20Library%20-%20Base%20Services.jpg>
 last night and I was reminded that Windows has full support for 
multi-Processes of course, but how to do this from managed code? Has anyone got 
experience in this?

Greg K

Reply via email to