.NET Remoting and DCOM

[=?Utf-8?B?Q2hyaXN0aWFuIEhhdmVs?=]

Hi,

in a existing application (DCOM server and client, both in VC++) we have
very often problems with the DCOM-configuration.
Is the requiered configuration (open ports) in applications using .NET
remoting much more easier than in DCOM applications?

What is with the performance, if the DCOM server has a .NET remoting object
client and the DCOM client (VC++) uses the .NET remoting object as the server?

Happy new year
Christian

[Willy Denoyette [MVP]]

Re: .NET Remoting and DCOM

"Christian Havel" <ChristianHavel @discussions.mi crosoft.comwrot e in
message news:064F1E75-50FD-4052-A437-6C0F2C24079D@mi crosoft.com...

Hi,
>
in a existing application (DCOM server and client, both in VC++) we have
very often problems with the DCOM-configuration.

What kind of problems?

Is the requiered configuration (open ports) in applications using .NET
remoting much more easier than in DCOM applications?
>

Are you talking about open ports at the Firewall ?
Whatever you are using, Remoting or DCOM you will have to open the ports you
are using at the firewall. DCOM uses the port 135 plus the port range you
have configured for the DCOM server's endpoints. When using .NET Remoting
(not using any authentication protocol), you'll have to open the ports you
are binding to in your Server's endpoint and the ports you are eventually
using for call backs.
If you wan't Remoting with authentication support, you'll have to open the
ports used by the authentication protocol selected (NTLM, Kerberos etc...).

What is with the performance, if the DCOM server has a .NET remoting
object
client and the DCOM client (VC++) uses the .NET remoting object as the
server?
>

Hmmm.. Not sure what you mean by this, DCOM clients cannot call Remoting
objects. What you could do however, is use EnterpriseServi ces and drop your
..NET classes in a COM+ server application, that way they are exposed to
native (DCOM) clients as well as to .NET clients using the DCOM protocol.

Happy new year

Same for you.
Willy.

[=?Utf-8?B?Q2hyaXN0aWFuIEhhdmVs?=]

Re: .NET Remoting and DCOM

Hi Willy,

thanks for your feedback
Christian

"Willy Denoyette [MVP]" wrote:

"Christian Havel" <ChristianHavel @discussions.mi crosoft.comwrot e in
message news:064F1E75-50FD-4052-A437-6C0F2C24079D@mi crosoft.com...

Hi,

in a existing application (DCOM server and client, both in VC++) we have
very often problems with the DCOM-configuration.

>
What kind of problems?
>

Is the requiered configuration (open ports) in applications using .NET
remoting much more easier than in DCOM applications?

Are you talking about open ports at the Firewall ?
Whatever you are using, Remoting or DCOM you will have to open the ports you
are using at the firewall. DCOM uses the port 135 plus the port range you
have configured for the DCOM server's endpoints. When using .NET Remoting
(not using any authentication protocol), you'll have to open the ports you
are binding to in your Server's endpoint and the ports you are eventually
using for call backs.
If you wan't Remoting with authentication support, you'll have to open the
ports used by the authentication protocol selected (NTLM, Kerberos etc...).
>

What is with the performance, if the DCOM server has a .NET remoting
object
client and the DCOM client (VC++) uses the .NET remoting object as the
server?

>
Hmmm.. Not sure what you mean by this, DCOM clients cannot call Remoting
objects. What you could do however, is use EnterpriseServi ces and drop your
..NET classes in a COM+ server application, that way they are exposed to
native (DCOM) clients as well as to .NET clients using the DCOM protocol.
>

Happy new year

>
Same for you.
Willy.
>
>
>