remoting general

[Tom]

Hi friends

I am new to remoting so this may sound silly. I don't understand remoting, I
think its suppose to be client / server but why is it that you always need
to attach somesort of service.dll to both the client and the server ? so
what I don't understand is how can I implement server logic on client calls
if the dll must be attached to both the client and the server ? say if I
want to perform some sql queries on the server and I embed this logic in the
service.dll but then this dll must also be attached as a library for the
client. the problem is when you distribute this application on a client site
there'll be no sql db.. how can I resolve this ?

Thanks
Tom

[Bonj]

Remoting is for when you want to execute code, but execute it on another
('remote') machine.

why is it that you always need
to attach somesort of service.dll to both the client and the server ?
The client has to have knowledge of the class because it has to know how to
call it, and the server obviously has to have knowledge of it in order to
know how to execute it. (If it is a large volume of code, then you may be
able to use an interface, the client just having the interface and the server
has the interface and a class derived from it, but I've never tried that).
The client's calling the methods, and the results are returned to the
client. But the code's actually running on the server, and any information
will be relative to the server machine's frame of reference - e.g. say if you
retrieve information about the file system, it will be the file system of the
server. And it will use the server's processor.

However it is probably not the best idea to use remoting just in order to
execute queries on a SQL server - SQL server runs its own service in order to
handle these.
"Tom" wrote:
Hi friends

I am new to remoting so this may sound silly. I don't understand remoting, I
think its suppose to be client / server but why is it that you always need
to attach somesort of service.dll to both the client and the server ? so
what I don't understand is how can I implement server logic on client calls
if the dll must be attached to both the client and the server ? say if I
want to perform some sql queries on the server and I embed this logic in the
service.dll but then this dll must also be attached as a library for the
client. the problem is when you distribute this application on a client site
there'll be no sql db.. how can I resolve this ?

Thanks
Tom

[Nick Malik]

Hi Tom,

For you, I'm going to strongly recommend that you pick up a copy of
"Advanced .NET Remoting" by Ingo Rammer.
http://www.amazon.com/exec/obidos/AS...692560-9975161

This will do an excellent job of explaining why you need THREE sets of
classes. One set for the client, one for the server, and one set of
interfaces. The interface classes are shared, and allow the definition of
the calling parameters for remoting to work. (This really is a good book,
BTW.)

If you want to set up a server-side operation, web services may be easier.
You create the web service and you can test the server easily. Then you do
your client development to consume it. For me, it is simpler to develop. It
is also harder to secure, and SOAP can be a little slower than binary
remoting.

Good Luck,
--- Nick

"Tom" <to********@optushome.com.au> wrote in message
news:41***********************@news.optusnet.com.a u...

Hi friends

I am new to remoting so this may sound silly. I don't understand remoting, I think its suppose to be client / server but why is it that you always need
to attach somesort of service.dll to both the client and the server ? so
what I don't understand is how can I implement server logic on client calls if the dll must be attached to both the client and the server ? say if I
want to perform some sql queries on the server and I embed this logic in the service.dll but then this dll must also be attached as a library for the
client. the problem is when you distribute this application on a client site there'll be no sql db.. how can I resolve this ?

Thanks
Tom