I have a service which has both an IPC and TCP remoting channel. A client
can use either to access my service and I talk to the clients via a callback
they pass to me. If I try to have the service talk to another instance of
the service running on a different machine, the callback fails and an
exception is thrown "Unable to case object of type
'System.Runtime.Remoting.Identity' to type
'System.Runtime.Remoting.ServerIdentity'. Any ideas on why this doesn't work
across machines?
If I take out the one line of code where I register the IPC channel,
everything works fine.

hi
the name space System.Runtime.Remoting.Channels.Ipc can be used for client
and services which are runnning in the same machine.

this can be ONLY used when the 2 parts --client and server r in the same
machine....

so probably ur error is due to the fact that u used IPC and u are trying to
use the server remotable component from a different machine.

Thanks
Senthil
http://dotnetcrunch.blogspot.com

"dr" <dr (AT) discussions (DOT) microsoft.com> wrote

I guess I wasn't clear - I'm using TCP between machines and IPC to talk to
clients on the local machine. I actually found a workaround which makes no
sense - if I set the TCP channel priority higher than the IPC channel, the
TCP callbacks start working - it almost appears to be a bug in the .NET
framework since it doesn't make any sense to me why it would fix the problem.

"SenthilVel" wrote:

oh ok.....But what do u think the bug may be ?
The priority betweeen TCP and IPC ?

,,,,
Senthil
http://dotnetcrunch.blogspot.com
"dr" <dr (AT) discussions (DOT) microsoft.com> wrote

I think the bug is the fact that having an IPC channel just sitting there
causes the failure to occur in the TCP channel callback. They should be two
completely isolated things (at least I would assume they would be).

"SenthilVel" wrote: