Reputation: 4039

.NET Remoting - DLL Referencing Dilemma

I have created two projects to understand the basics of .NET Remoting.

Server Project: I created the class library of RemoteObject within server solution.
Client Project: I create proxies from this project to use RemoteObject of Server.

The problem: Client has two know about the types that it is remoting. But how can it do that? Do you think Client should reference RemoteObject dll in server project. I think it is useless if these projects are distributed on different machines. Similarly, copying the dll to the client sounds bad. So what the optimal solution should be?

Thank you,

Upvotes: 0

Answers (4)

user2991288

Reputation: 376

I think the real unanswered question is:

can the server dll for remoting be deployed "alone" without copying side by side any external reference to the dll where interface is applied ?

I mean, the server do incorporate the interface statically (so IMyFooClass.dll do not need to be copied), and the client do use remoting with a reference to the same IMyFooClass.dll.

Also, may i use some "standard" class, like an Hashtable, to be registered by the service and send informations to client wothout requiring any reference that need to be added on both client and server side ?

I'm looking for a way to decoupling server and client development, without sharing any common types libraries, but using only standard types like expando objects, collections, hashtables, and so on

Upvotes: 0

Daniel Mošmondor

Reputation: 19976

Create the interface that has the functionality you need in separate dll.

In server, derive from that interface and implement functionality. In client, reference the interface and create remote proxy for it, which will give you access to server implementation but at the same time you won't ship your server code with the client.

Upvotes: 1