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 <[email protected]> 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!
