Have you ever seen this error?
System.IO.FileLoadException: Could not load file or assembly ‘nameOfAssembly’, Version=specificVersion, Culture=neutral, PublicKeyToken=publicKey’ or one of it's dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
This means you’ve replaced the specific version of the third party assembly with either an earlier or an updated version. The assembly that uses it is compiled to point to a specific version of the assembly and now will not load. I’ve seen this the most with applications that use log4net and/or NHibernate and third party assemblies that also use log4net and/or NHibernate.
Sometimes you just can’t recompile code, but you want to update the version the assembly uses. Sometimes it’s troublesome (or even impossible) to go back to all of the third party assemblies and get their source and recompile everything to use the same version. This may be the biggest pain some people see in trying to use and upgrade OSS. But if you know what’s going on, it’s very easy to make everything work happily together without a lot of work.
I’ve fought for hours trying to figure out and correct this error. I’ve found that there is an easier alternative and I wanted to share so that others could see it is not that hard to deal with. It’s possible to make code look for an updated assembly (or an earlier version) by adding some elements to the config file.
This is done through a binding redirect. In the configuration file for the application or DLL that uses the assembly, you include something like this:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NHibernate"
publicKeyToken="aa95f207798dfdb4"
culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.0.0.4000" newVersion="2.0.0.4000" />
</dependentAssembly>
</assemblyBinding>
</runtime>
You are instructing the application or DLL that during runtime, for a particular dependent assembly to use a particular version when an application and/or other assembly is looking for the older version.
You can see here that I pointed the application from all versions of NHibernate 0.0.0.0-2.0.0.4000 to use 2.0.0.4000, even though the application was only looking for 2.0.0.1001. This helps other assemblies in the same AppDomain (normally all of the assemblies within your application’s executing code) also update whatever versions they are tied to to also use the same version.
The error in the above picture occurred in Castle.Facilities.NHibernateIntegration.dll, but I didn’t add a Castle.Facilities.NhibernateIntegration.dll.config file. It wasn’t the entry point for my application. I have another asssembly, let’s call it Foo.exe, that references both Castle.Facilities.NHibernateIntegration.dll and NHibernate.dll. Foo.exe itself is actually using an updated reference to NHibernate version 2.0.0.4000. The NHibernateIntegration was compiled against NHibernate version 2.0.0.1001. I need to add a Foo.exe.confg file and add the code above to it. That way when Castle goes looking for any version of NHibernate between 0.0.0.0 and 2.0.0.4000, the AppDomain instructs it to use version 2.0.0.4000. If another assembly was looking for another version of NHibernate, it would also be instructed to use 2.0.0.4000.
Keep in mind this is not recommended for use when there are breaking changes between two versions of a dependent assembly (due to errors or inconsistent behaviors). Hopefully this will help you if you ever run into this issue.
