When you add a WebReference, VS.NET creates a wrapper class for you which
contains the interface for the web service's methods. That's then compiled
into the client. So it's really no different -- you have to have the
interface definition. The same for remoting. You don't have to have the
actual object definition on the client -- just an interface. For example,
you could create an assembly name RemotingInterfaces.dll with an interface
defined as follows:

interface MyRemoteObjectInterface
{
   string DoSomething(int a);
}

Then, on your server, you could create an assembly names ServerObjects.dll
with a class that implements this interface, e.g.

class MyRemoteObject : MarshalByRefObject, MyRemoteObjectInterface
{
   string DoSomething(int a) { return a.ToString(); }
}

The ServerObject.dll would lives on the server only -- the client does not
have access to it and thus has no access to the implementation of the class.
The client only has requires access to the RemotingInterfaces assembly. For
more info on this form of remoting and how to set it up, see:

http://www.genuinechannels.com/Content.aspx?id=28&type=1

Ken

Ken beat me to the answer!  But I'll give my own $0.02, anyway.

One of the 'dangers' of using an IDE like Visual Studio.NET is that you
are missing a lot of a mechanics because the wizards are doing a lot of
the work for you.  Certainly, this makes life much easier from a
development standpoint, but time-and-time again I've seen it lead to
the kind of confusion which you are facing right now.

There is no magic -- the client needs to know SOMETHING about the
server if it wants to interact with it.  You could devise a completely
late-bound remoting mechanism, so that absolutely nothing exists on the
client, but the client code would still need to know "I need to call a
method named 'Foo' and pass in two parameters."  Do you really want to
hard-code that kind of logic in the client, with no automatic means for
verifying that the client and the server are no longer in sync?

Look at it another way -- why not prototype some client code that would
look the way that you want.  Next, determine how you could possibly
achieve that goal.

If you want to write statically-bound C# or VB code like this:

theServer.DoSomething(5)

then it is clear that the client code needs to have infomation about
the server, because that's the nature of these languages.  There is no
way to compile that code if the code does not know about the type of
'theServer".

If, instead, you want to do something late-bound such as:

theServer.ExecuteMethod("DoSomething", 5)

then you can get away with the client not knowing anything about the
DoSomething method on the server.  You still need some generic remoting
type for 'theServer', so that the ExecuteMethod is known to the client,
but you could concievably reuse this code for all of your remoted
objects.

Of course, if the server modifies the DoSomething method to take
exactly two arguments, your client code will break and you won't know
this at compile time; you'll have to hope you catch it during
regression testing.

So, really, I encourage you to write some client code that looks the
way you want, and then decide if it's possible, given the constraints
of the language you are using.  [There are completely late-bound
languages out there, so maybe they'd be a better fit for your
development style.]