.NET interprocess communication

[ASB]

At the mo it's mainly hypothetical. It's a possible migration of a system. This has a number of different front ends. I'm just looking at options at the moment. One process would be preferable

[mcquiggd]

Remoting isnt really as complex as it appears... simplist way is to specify the setup of channels, formatters, types etc in the config file, dont hardcode them for obvious reasons

Is the object you are calling into already instantiated, e.g. created by a windows service, or is it simply loading a DLL and calling a method? If the latter id look at using ApplicationDomain and loading the DLL into the same process, if possible in your circumstances.

[ASB]

Cheers guys. Look like I'll have a read up on remoting. The serialization cost is probably not an issue for me.

[scotspine]

google eh? and you thought remoting was a faff?

"proper "Windows" unabstracted way of sending data." - ?????????????

mqgd's prompt of asynch vs synch is important. named pipes as above looks to be quite tightly coupled with thread blocking ocurring if the client fails to read completely. you might want something that is a bit looser?

[mcquiggd]

First thought is an Application Domain that loads the DLL (if indeed that is what you are calling) into the same Process... or using the Process class....

Synchronous or asynchronous communication required...?

[ASB]

Ok, I have a .NET process which needs to call an object in a different .NET process. Remoting just seems such a faff, any easier way ?

In COM for example just create a reference and call it. It will kindly start the process if it isn't running etc.

It seems there is a bit more to it than that with .NET.