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!
You could try to use PROCMON to see where your application is
searching for the assembly.
These tools show all the file access, registry access, ... by an
application.
- sandrino.be
On Jul 2, 2:39 pm, sean <smcco...@gmail.com> wrote:
> 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!
I know where the application is looking - it's the "standard" assembly search path, starting from the same directory as the client exe. What's weird is it's not searching for the assemblies listed in the app manifest, and it's not using assemblies that have *already been loaded.*
On Sat, Jul 4, 2009 at 4:48 AM, Sandrino <cont...@sandrino.be> wrote:
> You could try to use PROCMON to see where your application is > searching for the assembly. > These tools show all the file access, registry access, ... by an > application.
> - sandrino.be
> On Jul 2, 2:39 pm, sean <smcco...@gmail.com> wrote: > > 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!
|
