Question

I have an Assembly A, this Assembly dynamically loads Assemblies B, C, and E. And it’ll load more in the future.

Issue one:
B references F and G, when I try to execute methods in an instance of a type declared in B, from A, I get an exception telling me that F wasn’t found, of course.
Questions:

1. How can I reference F and G when I dynamically load Assembly
   B, assuming F and G are in the same folder as B?
2. How can I reference F and G when I dynamically load Assembly
   B, assuming F and G are in a different folder?

Issue two:
This pretty much comes from the fact that, in trying to quickly test some functionality, I copied the referenced assemblies from B‘s binaries folder to A‘s, which resulted in the following exception:

Could not load file or assembly ‘log4net, Version=1.2.10.0,
Culture=neutral, PublicKeyToken=1b44e1d426115821’ or one of its
dependencies. The located assembly’s manifest definition does not
match the assembly reference. (Exception from HRESULT: 0x80131040)

I assume this comes from the fact that I’m using a different version of log4net than one of the dependencies of B does.
Question:
What measure can I take to avoid this kind of versioning issues?
Will fixing issue one fix this issue? If not, why?

---

Should I use Autofac for this?
Will it help me? How?

Keep in mind the idea of Assembly A is to take “plugins”, and in that order, declaratively pointing at the Assemblies or their dependencies isn’t an option

Answer 1

As long as the assemblies are compatible in version, you can instruct the CLR to load a specific version regardless of what version the assembly you depend on was compiled against.

For instance, adding this snippet to your configuration file will redirect 1.0.0.0-2.0.0.0 of System.Web.Mvc assembly to use 3.0.0.0.

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
            <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

You can use the same principle for any assembly, e.g. log4net.

That said, your preferred solution should be to obtain a version compiled against the correct assembly version. For example, log4net is available in source and therefore easy to download and recompile with the updated dependencies.

If you are unsure exactly what assembly is causing the problem, there is a tool called Fusion Log Viewer (fuslogvw.exe) which is installed along with the .NET framework. It’s a bit quirky to use but will show you exactly where .NET searches for assemblies and any errors that occur during assembly resolution.