Just getting back to this now...
Both assemblies are referencing the .NET 3.5 version of Autofac and the 4.0
version is out because these assemblies are being loaded into a .NET 3.5
process (3rd party native app that hosts .NET 3.5 for plugins).
To add a probing path it would need to go in the 3rd party host app's config
file and the probing path would be outside it's base directory, so unless
I'm mistaken that won't work.
What's interesting is that having Autofac.dll for .NET 3.5 in the same
folder as my plugin seems to work, but my AssemblyResolve handler has to
resolve other referenced assemblies in the same folder.
I can think of various other ways I can change the code to solve my problem,
but I'm just trying to understand this behaviour.
Thanks all for your responses. I'll do some more testing and maybe post on
StackOverflow.
On Tue, Sep 20, 2011 at 3:37 AM, David Kean <david.k...@microsoft.com>wrote:
> If overrides are not getting called, then is a sign that the runtime
> seeing that that the virtual method takes a different ContainerBuilder type
> (ie 3.5) to the override (4.0 or vice versa) and hence are not seen as
> compatible.****
>
> ** **
>
> I just ran this by Nick (who owns Autofac and is down the hall from me) and
> we both agree that you should just load 4.0 version and not attempt to load
> the 3.5 version. This should just work and given that they have the same
> name and key, you won’t even need to add any binding redirects.****
>
> ** **
>
> *From:* ozdotnet-boun...@ozdotnet.com [mailto:
> ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Matt Siebert
> *Sent:* Sunday, September 18, 2011 11:28 PM
> *To:* ozDotNet
> *Subject:* Assembly binding woes****
>
> ** **
>
> 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.****
>
