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