Newtonsoft.json assembly package version mismatch
Solution 1
Found solution, try with:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Solution 2
You can modify assembly-binding configuration and add a redirect. See Redirecting Assembly Versions on MSDN.
Basically you want to add following snippet to your app.config
or web.config
file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<!--
Assembly versions can be redirected in application,
publisher policy, or machine configuration files.
-->
<bindingRedirect oldVersion="1.0.0.0-4.5.11.0" newVersion="4.5.11.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
EDIT
Why do you need to redirect assembly versions? Even though SocketIO4Net supports newer versions of Newtonsoft.Json, it was compiled against a single version (4.0.8 in your case). This version is stored in the DLL and it is used to load DLLs SocketIO4Net depends on.
Note that NuGet dependencies are not the same as DLL/runtime dependencies - NuGet dependency on Newtonsoft.Json >= 4.0.8 only means that you will be allowed to install SocektIO4Net into a project that has a newer version of Newtonsoft.Json, it has nothing to do with runtime settings.
That being said, recent NuGet versions should add assembly-binding-redirects automatically for you if your project has app.config or web.config file.
Solution 3
The above solutions are correct but there is one more point that should not be forgotten: the app.config content was the same as the above solutions.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
But it's a good idea to check if it's up to date. In my case, Newtonsoft.JSON (v.6.0.4) has come to depend on another package.
There are two option;
- Update (Newtonsoft.JSON package) last versions.
- Update app.config file in the version numbers.
And last advice, if you are working with more than one project, eg. exe-dll and check both versions if there is Newtonsoft.JSON.
Solution 4
Had this same issue.
Just resolved it.
It happened after NuGet was used to install Ext.NET which has a dependency for Newtonsoft.JSON.
There was already a Newtonsoft.JSON.dll file in /bin (and obviously a reference to it in the web.config file) folder without checking I started the NuGet Package-Install procedure while debugging(so the file probably had a lock).
On the runtime error window it will tell you on the stack trace what part of the manifest it has a problem with, mine was major version so I checked the install package version. and it was 1 major version out. Found the original NuGet file under: "[physical path]/../packages/Newtonsoft.Json.[version]/lib/[.net version]/"
Both Manifest and Library was there so copied it into /bin folder, updated the root web.config assembly information and it worked.
Code samples: Before
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
After
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
Hope this helps
Solution 5
I was working on an old project recently. I needed to update our Newtonsoft.Json.dll, since I had to utilize a "new" API which required a newer version, but I still had other DLLs that required the old version.
bindingRedirect you say? Nope. It kept complaining about the manifest mismatch.
Separate codeBase tags? Nope. It kept complaining about the manifest mismatch.
The problem was, apparently, that the old version of Newtonsoft.Json.dll (3.0.0.0) does NOT have a PublicKeyToken, but the "new" version (4.5.7.1) DOES have a PublicKeyToken. Therefore they couldn't share the same dependentAssembly-tag.
This is what I ended up with:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="" culture="neutral"/>
<codeBase version="3.0.0.0" href="bin\Newtonsoft_Old\Newtonsoft.Json.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral"/>
<codeBase version="4.5.0.0" href="bin\Newtonsoft.Json.dll" />
</dependentAssembly>
Related videos on Youtube
Bitsian
Updated on August 15, 2020Comments
-
Bitsian almost 4 years
I am trying to use SocketIO4Net to create socket.io client in .net. Itseems SocketIO4Net has a dependency of Newtonsoft.Json >= 4.0.8. I also am using PushSharp library which has a Newtonsoft.Json dependency of >= 4.5.10. I got NewtonSoft.Json 4.5.11 when i first installed PushSharp and I thought this version should support SocketIO4Net as well since its a higher version but i get this error whenever am trying to connect to socket.io server.
Could not load file or assembly 'Newtonsoft.Json, Version=4.0.8.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have been banging my head all day with these dependency issues, I would be very grateful if someone can point me in the right direction.
-
Chris Mantle almost 11 yearsFYI, we've also come across this, with exactly the same versions of Newtonsoft.Json. In our case, it was PlainElastic.NET that was bringing in the old 4.0.8 version. Perhaps there is some inconsistency in the versions of Newtonsoft.Json that are held in NuGet...?
-
jww over 5 yearsRelated, and uses Newtonsoft.Json as an example: Assembly Loading Version Mismatch: Why is it loading?. Also see Is it possible to replace a reference to a strongly-named assembly with a “weak” reference?.
-
StayOnTarget over 4 years
-
-
Bitsian almost 11 yearsWhen i put this code in my App.Config of worker role, the symbols dont load and i get the error "Microsoft.ServiceBus.pdb is not loaded". I am not sure why this would come up when I make the above assembly redirect. It doesnt happen when i remove the re direct. Any idea?
-
Bitsian almost 11 yearsWhen i put this code in my App.Config of worker role, the symbols dont load and i get the error "Microsoft.ServiceBus.pdb is not loaded". I am not sure why this would come up when I make the above assembly redirect. It doesnt happen when i remove the re direct. Any idea?
-
Bitsian almost 11 yearsAnd i was wondering wouldnt i need to re direct from 4.0.8 to 4.5.11 ? I see 4.5.11 in both the old and new versions in ur code?
-
Bitsian almost 11 yearsAnd i was wondering wouldnt i need to re direct from 4.0.8 to 4.5.11 ? I see 4.5.11 in both the old and new versions in ur code?
-
Miroslav Bajtoš almost 11 years@Bitsian I don't know what might be the reason for "Microsoft.ServiceBus.pdb is not loaded". Probably another bug that was hidden by assembly binding error before.
-
Bitsian almost 11 yearsOk! What about 4.0.8? do i need to mention that in the old version? because thats what the socketio4Net library expects!
-
Miroslav Bajtoš almost 11 yearsYou can use range for oldVersion. In my example, "1.0.0.0-4.5.11.0" means all versions starting with 1.0.0.0 up to 4.5.11.0 (which includes 4.0.8.0).
-
PaulBinder over 6 yearsAccording to msdn.microsoft.com/en-us/library/7wd6ex19.aspx "You cannot redirect versions for assemblies that are not strong-named. The common language runtime ignores the version for assemblies that are not strong-named."
-
David Parker about 4 yearsThis was the solution for my Visio add-in ... thank you