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