Matt, can you try and use a probe path using a symbolic linked subdirectory to the real directory?
On 19 September 2011 18:27, Matt Siebert <[email protected]> wrote: > Hi all, > > I have some assembly binding weirdness happening that I don't fully > understand. I have some theories but I'd like to understand it a bit > better. > > I have a solution with two primary entry points: > > 1. A .NET 4.0 WPF application > > 2. A .NET 3.5 class library that is loaded as a plugin for a 3rd party > application > > Both of these assemblies have a dependency on Autofac, but the .NET 3.5 > class library uses Autofac for .NET 3.5 while the .NET 4.0 WPF app uses > Autofac for .NET 4.0. > > Obviously, when sending build output to the same folder one Autofac.dll > overwrites the other so I've added post-build commands to move Autofac to > relevant sub-folders ("NET35" and "NET40"). > > For the WPF app I've added an app.config file with a <probing > privatePath="NET40" /> element which correctly resolves the dependency. > > For the .NET 3.5 DLL it's a little trickier. I can't add a <probing /> > element since it would need to go in the 3rd party host app's config file, > and the path would be outside the host's appbase path. Instead, my DLL > provides an AssemblyResolve event handler that finds and loads the DLL. > > This all works fine. > > The plugin DLL described so far, let's call it "Lib1.dll", implements a > type, say "DerivedType", that is inherited from BaseType in Lib2.dll. > DerivedType overrides a method with a ContainerBuilder parameter so it can > add registrations to the container. The sequence of events is as follows: > > 1. Host app loads Lib1.dll and calls DerivedType.Startup > 2. DerivedType.Startup calls BaseType.Startup > 3. BaseType subscribes to AssemblyResolve and calls SomeMethod that > directly uses a ContainerBuilder > 4. The AssemblyResolve handler finds and loads Autofac.dll > 5. BaseType.SomeMethod executes and calls > SomeVirtualMethod(ContainerBuilder builder) > > DerivedType in Lib1.dll overrides SomeVirtualMethod but this doesn't get > called, however, BaseType.SomeVirtualMethod does execute. > > This seems consistent with the dependency being loaded into the LoadFrom > context and therefore not being used to resolve dependencies of Load context > assemblies, but the code is using Assembly.Load(), not LoadFrom(). > > I'm not sure if I've explained this very well, but hopefully somebody can > shed some light on why this is happening? > > Cheers. > -- regards, Preet, Overlooking the Ocean, Auckland
