I'm working on a .NET remoting application, and I've read in a number
of places that the .dll that exposes the shared objects in the
remoting interface needs to be copied to the same directory as the
executable for the application, in order for the runtime to find the
assembly when it comes time to access server instantiated objects on
the client app.

It seems strange though, that I can include the shared .dll as a
reference in my client (wherever that dll happens to live ), I can
create instances of the shared objects local to the client from that
shared library (without remoting, to demonstrate that the shared
assembly is loaded), but that shared object returned through remoting
will generate an exception if that same .dll isn't located in a
particular place.

And actually, it gets weirder - I implemented a handler for
AppDomain.AssemblyResolve, and found that if I simply return the
*already loaded* shared assembly remoting needs by pulling it from
AppDomain.CurrentDomain.Load(AssemblyName) everything works.  What
gives?

It looks like the assembly search path for remoting is different from
that used for the application itself, and specifically, that it
doesn't even look for assemblies in the currently loaded AppDomain.
Am I missing something?  This seems to be a common problem out there.
Thank for any help!

Reply via email to