This is expected behavior.  The remoting infrastructure needs to see *some*
metadata describing the method signatures of the remote methods in order to
build transparent proxies.  This metadata can be from the actual server
assembly, from a soapsuds-generated assembly, from an assembly containing
only an interface definition (assuming you're only using
singleton/singlecall objects and not client-activated types), or from a
hand-typed "pretend" class that you write so that it just happens to have
the right method names & signatures (effectively you pretending to be the
soapsuds tool).  If you want to distribute the actual server assembly, then
any assemblies it depends on will also have to be distributed.

The two typical approaches are to just use soapsuds, or to have the client &
server use an interface(s) to communicate.  In the latter case, you'd put
the interface(s) into their own assembly that both the client & server then
use.  The server would reference this assembly and implement the
interface(s) as needed.  This assembly would also be distributed to clients
so that they could program against the interface(s) w/o needing the actual
implementation assembly around during development- or run-time.

-Mike
http://staff.develop.com/woodring
http://www.develop.com/devresources

----- Original Message -----
From: "Casey Richardson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 29, 2002 3:38 PM
Subject: [ADVANCED-DOTNET] Remoting metadata


> I have a Remoting server that I am running inside of IIS.  The
> implementation of the server, in assembly A, calls a method on a class
> located in another assembly that I have, call it assembly B, which is in
> the bin subdir of the virtual dir.
>
> To get the metadata to the client, I distributed the dll for the impl of
> the server to the client.  This raises a FileNotFoundException, because
> fusion cannot resolve assembly B.
>
> However, if I use soapsuds to generate a metadata only assembly and
> distribute that to the client, then it works exactly as planned.
>
> Any thoughts?
>
> -Casey
>
> You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or
> subscribe to other DevelopMentor lists at http://discuss.develop.com.
>

You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced 
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.

Reply via email to