I've got a FileLoadException for Newtonsoft, looking for version 6.0.0.0 when I've installed 11.0.2.0. The packages.config is set to look for the newer version, as is the web.config. The version of the .dll in the references is 11, as is the temporary ASP files in the framework folder outside of my solution. I've tried force uninstalling newtonsoft and installing the latest version in the package manager console as well.
In code and out of it, I cannot find any place where the version 6.0.0.0 is defined. Where is this being set?
Here is the fusion log(which you can see is trying everything it can to get a match before failing):
=== Pre-bind state information ===
LOG: DisplayName = Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed(Fully-specified)
LOG: Appbase = file:///C:/Repos/MyProjectPath/
LOG: Initial PrivatePath = C:\Repos\MyProjectPath\bin
Calling assembly : System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Repos\MyProjectPath\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/MyProjectFolder/20c630f1/c09fb4a6/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/MyProjectFolder/20c630f1/c09fb4a6/Newtonsoft.Json/Newtonsoft.Json.DLL.
LOG: Attempting download of new URL file:///C:/Repos/MyProjectPath/bin/Newtonsoft.Json.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
The solution is probably not useful to most people having assembly reference problems, but here is what I had to do for the 1 in 1000 who has a similar problem.
The build correctly redirected version 6.0.0.0 references from the calling assembly(System.Net.Http.Formatting) to 11.0.0.0, as seen in the detailed output for build logs:
Unified primary reference "Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed". (TaskId:108)
7> Using this version instead of original version "6.0.0.0" in "C:\Repos\MySolutionFolder\NugetPackages\Microsoft.AspNet.WebApi.Client.5.2.3\lib\net45\System.Net.Http.Formatting.dll" because of a binding redirect entry in the file "Web.config". (TaskId:108)
7> Using this version instead of original version "6.0.0.0" in "C:\Repos\MySolutionFolder\NugetPackages\Microsoft.AspNet.WebApi.Core.5.2.3\lib\net45\System.Web.Http.dll" because of a binding redirect entry in the file "Web.config". (TaskId:108)
7> Using this version instead of original version "6.0.0.0" in "C:\Repos\MyReferencedProjectPath\bin\Debug\MyLibrary.dll" because of a binding redirect entry in the file "Web.config". (TaskId:108)
7> Resolved file path is "C:\Repos\MySolutionFolder\NugetPackages\Newtonsoft.Json.11.0.2\lib\net45\Newtonsoft.Json.dll". (TaskId:108)
However, even though the web.config bindingRedirect was correct, in the app settings of the web.config was an element that, if not removed in the final build, would prevent the redirect from working at runtime. The following is the offending element in the web.config:
<?ap-config target="add[@key='Environment']/@value"
value="{@environment}"
when="true()" ?>
My particular solution involved a post-build event script that would remove this line from the file before placing it in the build output folder for every web project in my solution. Your particular app may require different solutions but the key take-away is even though the build output claims that the assembly reference was found via redirect, other things in the web.config caused the built version to break at runtime.
I don't know how to debug any deeper to trace this problem so you will just have to know that even successful build logs don't tell the whole story.