.NET Remoting & RTD

[Nick]

Hi there,

Can anyone tell me what RTD is? And can it be used for simple
interprocess communication? I am just interested in sending strings to a
previous instance.

I am currently using .NET Remoting via the "Windows Application
Framework", but unfortunately McAfee's crappy firewall is capable of
blocking the internal connection and causing any application that utilises
it to crash, it doesn't even raise an unhandled exception via the
"UnhandledException" event.

I had originally taken the .NET Remoting route a while back now as I
read that it was much preferable than DDE, which apparently now is a
deprecated technology.

Anyone got any advice on this? Thanks in advance.

Nick.

[Dave Kreskowiak]

Since you mentioned the "Application Framework", I'm assuming you're using
2005. If you want to communicate with a previous instance, you can check out
the System.Runtime.Remoting.Channels.Ipc namespace. You get all the benefits
of .NET Remoting without having to go through a network card to do it. It's
only for communicating with a process on the same machine.

http://msdn2.microsoft.com/en-us/lib...nnels.ipc.aspx

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The Roaming
Gnome</b></font>
"Nick" wrote:

Hi there,

Can anyone tell me what RTD is? And can it be used for simple
interprocess communication? I am just interested in sending strings to a
previous instance.

I am currently using .NET Remoting via the "Windows Application
Framework", but unfortunately McAfee's crappy firewall is capable of
blocking the internal connection and causing any application that utilises
it to crash, it doesn't even raise an unhandled exception via the
"UnhandledException" event.

I had originally taken the .NET Remoting route a while back now as I
read that it was much preferable than DDE, which apparently now is a
deprecated technology.

Anyone got any advice on this? Thanks in advance.

Nick.

[NickP]

Hey Dave,

Thanks a bunch, I didn't know this one existed. Great stuff, any ideas
why the Application Framework doesn't use this? It uses TCP unfortunately,
hence the firewall issues :-(

Nick.

"Dave Kreskowiak" <Da************@discussions.microsoft.comwrote in
message news:BE**********************************@microsof t.com...

Since you mentioned the "Application Framework", I'm assuming you're using
2005. If you want to communicate with a previous instance, you can check
out
the System.Runtime.Remoting.Channels.Ipc namespace. You get all the
benefits
of .NET Remoting without having to go through a network card to do it.
It's
only for communicating with a process on the same machine.

http://msdn2.microsoft.com/en-us/lib...nnels.ipc.aspx

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The Roaming
Gnome</b></font>
"Nick" wrote:

>Hi there,

Can anyone tell me what RTD is? And can it be used for simple
interprocess communication? I am just interested in sending strings to a
previous instance.

I am currently using .NET Remoting via the "Windows Application
Framework", but unfortunately McAfee's crappy firewall is capable of
blocking the internal connection and causing any application that
utilises
it to crash, it doesn't even raise an unhandled exception via the
"UnhandledException" event.

I had originally taken the .NET Remoting route a while back now as I
read that it was much preferable than DDE, which apparently now is a
deprecated technology.

Anyone got any advice on this? Thanks in advance.

Nick.

[Dave Kreskowiak]

Probably because IPC is limited to communication inside the same machine.
It's faster, but far less flexible. Going over the TCP/IP stack gives you
the flexibility of talking with another app on the same machine or on a
remote.

Some of the services I've written open up a TCP port so a management app can
talk to it. The service is used on workstations, but since I'm doing the
Remoting over TCP, I have the option of connecting my management app to any
machine and administering each service remotely.

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The Roaming
Gnome</b></font>
"NickP" wrote:

Hey Dave,

Thanks a bunch, I didn't know this one existed. Great stuff, any ideas
why the Application Framework doesn't use this? It uses TCP unfortunately,
hence the firewall issues :-(

Nick.

"Dave Kreskowiak" <Da************@discussions.microsoft.comwrote in
message news:BE**********************************@microsof t.com...

Since you mentioned the "Application Framework", I'm assuming you're using
2005. If you want to communicate with a previous instance, you can check
out
the System.Runtime.Remoting.Channels.Ipc namespace. You get all the
benefits
of .NET Remoting without having to go through a network card to do it.
It's
only for communicating with a process on the same machine.

http://msdn2.microsoft.com/en-us/lib...nnels.ipc.aspx

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The Roaming
Gnome</b></font>
"Nick" wrote:

Hi there,

Can anyone tell me what RTD is? And can it be used for simple
interprocess communication? I am just interested in sending strings to a
previous instance.

I am currently using .NET Remoting via the "Windows Application
Framework", but unfortunately McAfee's crappy firewall is capable of
blocking the internal connection and causing any application that
utilises
it to crash, it doesn't even raise an unhandled exception via the
"UnhandledException" event.

I had originally taken the .NET Remoting route a while back now as I
read that it was much preferable than DDE, which apparently now is a
deprecated technology.

Anyone got any advice on this? Thanks in advance.

Nick.

[NickP]

Hi Dave,

I understand what your saying but that's hardly relevant of the
application framework, as far as I am aware if only uses the communication
channel to pass arguments from a secondary instance does it not? Your code
is all custom made for the tasks that you mentioned here isn't it? I see
the benefit of talking across the network of course but just for multiple
instances it hardle seems worth it...

Or am I missing something?

Nick.

"Dave Kreskowiak" <Da************@discussions.microsoft.comwrote in
message news:EE**********************************@microsof t.com...

Probably because IPC is limited to communication inside the same machine.
It's faster, but far less flexible. Going over the TCP/IP stack gives you
the flexibility of talking with another app on the same machine or on a
remote.

Some of the services I've written open up a TCP port so a management app
can
talk to it. The service is used on workstations, but since I'm doing the
Remoting over TCP, I have the option of connecting my management app to
any
machine and administering each service remotely.

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The Roaming
Gnome</b></font>
"NickP" wrote:

>Hey Dave,

Thanks a bunch, I didn't know this one existed. Great stuff, any
ideas
why the Application Framework doesn't use this? It uses TCP
unfortunately,
hence the firewall issues :-(

Nick.

"Dave Kreskowiak" <Da************@discussions.microsoft.comwrote in
message news:BE**********************************@microsof t.com...

Since you mentioned the "Application Framework", I'm assuming you're
using
2005. If you want to communicate with a previous instance, you can
check
out
the System.Runtime.Remoting.Channels.Ipc namespace. You get all the
benefits
of .NET Remoting without having to go through a network card to do it.
It's
only for communicating with a process on the same machine.

http://msdn2.microsoft.com/en-us/lib...nnels.ipc.aspx

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The
Roaming
Gnome</b></font>
"Nick" wrote:

Hi there,

Can anyone tell me what RTD is? And can it be used for simple
interprocess communication? I am just interested in sending strings
to a
previous instance.

I am currently using .NET Remoting via the "Windows Application
Framework", but unfortunately McAfee's crappy firewall is capable of
blocking the internal connection and causing any application that
utilises
it to crash, it doesn't even raise an unhandled exception via the
"UnhandledException" event.

I had originally taken the .NET Remoting route a while back now as
I
read that it was much preferable than DDE, which apparently now is a
deprecated technology.

Anyone got any advice on this? Thanks in advance.

Nick.

[Dave Kreskowiak]

I don't know what their reasoning was, but from what I can make an educated
guess at is they used TCP by default because of it's flexibility. One
solution that works for communicating with remote processes acrossed
AppDomain boundries and network boundries, without having to change anything
in the code.

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The Roaming
Gnome</b></font>
"NickP" wrote:

Hi Dave,

I understand what your saying but that's hardly relevant of the
application framework, as far as I am aware if only uses the communication
channel to pass arguments from a secondary instance does it not? Your code
is all custom made for the tasks that you mentioned here isn't it? I see
the benefit of talking across the network of course but just for multiple
instances it hardle seems worth it...

Or am I missing something?

Nick.

"Dave Kreskowiak" <Da************@discussions.microsoft.comwrote in
message news:EE**********************************@microsof t.com...

Probably because IPC is limited to communication inside the same machine.
It's faster, but far less flexible. Going over the TCP/IP stack gives you
the flexibility of talking with another app on the same machine or on a
remote.

Some of the services I've written open up a TCP port so a management app
can
talk to it. The service is used on workstations, but since I'm doing the
Remoting over TCP, I have the option of connecting my management app to
any
machine and administering each service remotely.

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The Roaming
Gnome</b></font>
"NickP" wrote:

Hey Dave,

Thanks a bunch, I didn't know this one existed. Great stuff, any
ideas
why the Application Framework doesn't use this? It uses TCP
unfortunately,
hence the firewall issues :-(

Nick.

"Dave Kreskowiak" <Da************@discussions.microsoft.comwrote in
message news:BE**********************************@microsof t.com...
Since you mentioned the "Application Framework", I'm assuming you're
using
2005. If you want to communicate with a previous instance, you can
check
out
the System.Runtime.Remoting.Channels.Ipc namespace. You get all the
benefits
of .NET Remoting without having to go through a network card to do it.
It's
only for communicating with a process on the same machine.

http://msdn2.microsoft.com/en-us/lib...nnels.ipc.aspx

--
<i><b>RageInTheMachine9532</b></i><font size="-2">
"<i>...a pungent, ghastly, stinky piece of cheese!</i>" <b>-- The
Roaming
Gnome</b></font>
"Nick" wrote:

Hi there,

Can anyone tell me what RTD is? And can it be used for simple
interprocess communication? I am just interested in sending strings
to a
previous instance.

I am currently using .NET Remoting via the "Windows Application
Framework", but unfortunately McAfee's crappy firewall is capable of
blocking the internal connection and causing any application that
utilises
it to crash, it doesn't even raise an unhandled exception via the
"UnhandledException" event.

I had originally taken the .NET Remoting route a while back now as
I
read that it was much preferable than DDE, which apparently now is a
deprecated technology.

Anyone got any advice on this? Thanks in advance.

Nick.