Can't help, but that sounds like a well enough explained problem for
stackoverflow.com.
--
Regards,
Mark Hurd, B.Sc.(Ma.)(Hons.)
On 19 September 2011 15:57, Matt Siebert <mlsieb...@gmail.com> 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.
