Back in the days .NET tried to solve the so called DLL Hell with its GAC and versioning. It more failed than succeeded in doing so. Then Nuget came along and one thing was sure. With Nuget there is no GAC. Thus you might think no GAC, no versioning problems. Until you encouter this at runtime:
System.IO.FileLoadException : Could not load file or assembly '..., Version=..., Culture=neutral, PublicKeyToken=...' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
The error is pretty self-explanatory. But fixing it is not so straight-forward. There are numerous posts about this error (just search stackoverflow), and most users seem to solve this problem by just running the nuget update-package command in Visual Studio, which updates all the packages and refenreces in the Visual Studio solution. Understanding why this works is nowhere explained, at least I could not find it.
So in this article I will walk you through a scenario where I encountered this versioning error and how I solved it.
I had a solution with an ASP.NET Web Api project and several library projects, which were referenced by the web api. All the nuget packages in the solution were managed with extreme care, so that there were no versioning indescrepancies between same references in different projects. In other words I made sure that if for example Project 1 referenced the Newtonsoft.Json.dll from the Newtonsoft.Json.6.0.6 package and Project 2 had a reference to the Newtonsoft.Json.dll, Project 2 referenced it from the same 6.0.6 package and not an earlier version.
At one point in my main web api project I had to add a reference to the following package: Microsoft.AspNet.WebApi.Cors.5.2.2. This triggered an update of all the dependencies of the Microsoft.AspNet.WebApi.Cors.5.2.2 among which was Microsoft.AspNet.WebApi.Core.
I deployed my new web api .dll (note: without the Web.config), ran the web api project and got the following error:
Could not load file or assembly 'System.Web.Http, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
The first thing I checked was that all projects in my solution were referencing System.Web.Http 5.2.2.0 and not 5.1.0.0:
I did not trust the VS properties window, so I manually inspected all the .csproj in the text editor to see if the references were correct. And they were. Next I opened my web api .dll with JustDecompile:
I had serveral references to System.Web.Http and one of them was version 5.1.00. I then opened the .dll in ildasm:
The assembly manifest showed the same thing. So how could it be that my web api .dll was referencing and thus requiring two different versions of System.Web.Http? All my other projects in the solution were referencing the correct 5.2.2.0 version of System.Web.Http.
It turns out that if your project has a reference to some external Assembly 1 and this external Assembly 1 has a reference to a specific version of an Assembly 2, then your project .dll manifest will contain a reference to the specific version of Assembly 2.
In my case, my web api project was referencing System.Web.Http 5.2.2.0 but it was also referencing an Autofac.Integration.WebApi.dll. And this Autofac.Integration.WebApi.dll was built with a specific version reference to System.Web.Http 5.1.0.0. So despite the fact that my web api project had an explicit reference to System.Web.Http 5.2.2.0, after compilation, its assembly manifest had an additional reference to System.Web.Http.5.1.0.0.
But let's not forget how all this was brought about. A new Nuget package reference trigerred the update of several other packages. Yet there were other packages in the solution like Autofac.Integration.WebApi which depended on old versions of the updated packages. So all projects referencing System.Web.Http 5.2.2.0 and Autofac.Integration.WebApi ended up with two references in their assembly manifest: System.Web.Http.5.1.0.0 and System.Web.Http 5.2.2.0.
There are two solutions to this problem:
1. Update all your nuget packages. This could be quite a hassle if you have many projects and many nuget packages.
2. Add a binding redirect to your Web.config for example like this:
<dependentAssembly>
<assemblyIdentity name="System.Web.Http" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.2.2.0" newVersion="5.2.2.0" />
</dependentAssembly>
I should mention that when you upgrade a nuget package and this triggers and upgrade of dependent packages, Visual Studio is smart enough to put all the required binding redirects in your config files. So my problem really was that I did not deploy the Web.config after the update of the Microsoft.AspNet.WebApi.Cors package.
Still I don't like binding redirects and I think they signal potential problems at runtime. If Autofac.Integration.WebApi was built specifically with System.Web.Http 5.1.0.0, what guarantees that Autofac.Integration.WebApi will work with System.Web.Http 5.2.0.0?
In summary if you get the "Could not load file or assembly error", this means that either your projects or their references were built with a reference to a specific version of an assembly which is missing from your bin directory or GAC.
To solve this problem you need to wither update all your project references as well as the referenced assemblies themselves or add binding redirects to your application config file.
I hope this is useful!