How can I fix assembly version conflicts with JSON.NET after updating NuGet package references in a new ASP.NET MVC 5 project?

Question

I created a new ASP.NET MVC 5 web project in VS 2013 (Update 1) then updated all NuGet packages. When I build the project, I get the following warning:

warning MSB3243: No way to resolve conflict between "Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" and "Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed".

When I check the web.config, however, I see that a binding redirect is in place:

  <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>

Which is exactly what the warning advises.

How can I fix this warning?

Straightforward

Yes, I did a full rebuild. I also updated NuGet to latest, created a new solution and reproduced the exact same problem. – Straightforward

Answer 1

Here the steps I used to fix the warning:

• Unload project in VS
• Edit .csproj file
• Search for all references to Newtonsoft.Json assembly
  • Found two, one to v6 and one to v5
  • Replace the reference to v5 with v6
• Reload project
• Build and notice assembly reference failure
• View References and see that there are now two to Newtonsoft.Json. Remove the one that's failing to resolve.
• Rebuild - no warnings

Straightforward

I found two references, one for v6 and one for v5 but I deleted (not replaced) the v5 one. After that I didn't have any problems like "assembly reference failure" or two references to Newtonsoft.Json in the UI. I'm guessing someone stuffed up install.ps1 – Vergos

Thanks for the solution. I too deleted the older reference from the project file and had no problems. – Ripp

+1 - It really drives me crazy when I have to do stuff like this. It is why I always hesitate to click upgrade on the nuget package manager. – Lumpfish

I was having this issue and have fixed it by removing the extra reference I didn't realise was there. This is the link to the Microsoft Connect bug that is the root cause of the extra reference being there: connect.microsoft.com/VisualStudio/feedback/details/816725/…. – Klepac

Must have lost 2 hours working this out. [doffs virtual hat in Jim Lamb's direction] – Daugherty

Why oh why has Microsoft not built-in a check to Visual Studio / the build system to check for duplicated references in projects?! This sort of thing has been going on for too many years. Lost HOURS to this. – Standice

In my case there was to references to two different version of Newtonsoft.Json 11.0.1 and 11.0.2, although it was complaining about version 6.0. – Why

I had the same issue as @DanielLobo s. Anyway just deleted the reference to Newtonsoft.Json 11.0.1. And it fixed the error. Also note that I am using Visual Studio Community 2017. – Landfall

Answer 2

I had this problem because I updated packages, which included Microsoft.AspNet.WebApi that has a reference to Newtonsoft.Json 4.5.6 and I already had version 6 installed. It wasn't clever enough to use the version 6.

To resolve it, after the WebApi update I opened the Tools > NuGet Package Manager > Pacakge Manager Console and ran:

 Update-Package Newtonsoft.Json

The log showed that the 6.0.x and 4.5.6 versions were all updated to the latest one and everything was fine.

I have a feeling this will come up again.

Kendo

I was having the problem of multiple different versions in my solution that contains multiple projects, this totally fixed that and updated all to the latest JSON.net. Nice! – Favors

This was the easiest, most straight-forward solution that fixed my problem. Thanks! – Abdominous

Answer 3

I found to delete this section from the project file fix the problem.

<ItemGroup>
<Reference Include="Newtonsoft.Json">
  <HintPath>..\packages\Newtonsoft.Json.6.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>

Brownell

This is it. I suppose none of Newtonsoft.Json.6.0.1/6.0.3/6.0.5 match to binding redirection ''oldVersion="0.0.0.0-6.0.0.0"'' But i do not know how to write correct one – Lanctot

This was my problem as well, I'm not sure what added it. – Ackley

Worked for me. Error related to conflict between v6.0 and v12.0. The item group reference was to v11.0. So not sure what is happening but removing the item group seems to have solved it, at as far as removing the compile error. – Transact

Answer 4

I upgraded from Newtonsoft.Json 11.0.1 to 12.0.2. Opening the project file in Notepad++ I discovered both

<Reference Include="Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
      <HintPath>..\packages\Newtonsoft.Json.12.0.2\lib\net45\Newtonsoft.Json.dll</HintPath>
    </Reference>

and

<ItemGroup>
    <Reference Include="Newtonsoft.Json">
      <HintPath>..\packages\Newtonsoft.Json.11.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
    </Reference>
  </ItemGroup>

I deleted the ItemGroup wrapping the reference with the hint path to version 11.0.1.

These issues can be insanely frustrating to find. What's more, developers often follow the same steps as previous project setups. The prior setups didn't encounter the issue. For whatever reason the project file occasionally is updated incorrectly.

I desperately wish Microsoft would fix these visual studio DLL hell issues from popping up. It happens far too often and causing progress to screech to a halt until it is fixed, often by trial and error.

Interleave

This was exactly the problem. Thanks! – Gerlachovka

I also had two entries. Both exactly the same version but also this error. I deleted the second <Reference... - Node and the message is gone. Thanks for this hint! – Alexine

This is the exactly problem to me as well, I deleted the second Reference as he did and everything works perfectly again – Wilkey

Answer 5

If none of the above works, try using this in web.config or app.config:

<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>

Anselma

This is best suited for the situation when you have an existing project using the higher version and you add a dependency that's using an older version of the same package, so you redirect the old version to the new one. – Ism

Answer 6

The final solution to your assembly redirect errors

Okay, hopefully this should help resolve any (sane) assembly reference discrepancies ...

1. Check the error.

2. Check web.config after the assembly redirect. Create one if not exists.

3. Right-click the reference for the assembly and choose Properties.

4. Check the Version (not Runtime version) in the Properties table. Copy that.

5. Paste into the newVersion attribute.

6. For convenience, change the last part of the oldVersion to something high, round and imaginary.

Rejoice.

Benue

This answer saved me big time! I had a web application that was using a custom C# library, both used the same nuget package but the web application has an older version than the library and the redirect was not inclusive of the version that the library was using. – Sessoms

Answer 7

Remember that with the binding redirection

oldVersion="0.0.0.0-6.0.0.0"

You are saying that the old versions of the dll are between version 0.0.0.0 and version 6.0.0.0.

Seacock

oldVersion is bit of misnomer here actually, what you are saying is that your assembly/exe was built with a reference to a version in the range 0.0.0.0-6.0.0.0 and that the actually installed (and preferred) version is the value under newVersion (old version would be better phrased as "expected version" and new version would be better phrased as "actual available version") – Elocution

Answer 8

No one mentioned the following, which in my understanding is the correct solution:

Go the csproj of the project where the nuget is installed, and set the AutoGEneratedBindingRedirects to false.

<AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>

Full article in MSDN.

Brake

Answer 9

I updated my package and even reinstalled it - but I was still getting the exact same error as the OP mentioned. I manually edited the referenced dll by doing the following.

I removed the newtonsoft.json.dll from my reference, then manually deleted the .dll from the bin directoy. Then i manually copied the newtonsoft.json.dll from the nuget package folder into the project bin, then added the reference by browsing to the .dll file.

Now my project builds again.

Hundredweight

Answer 10

I had similar issue and just wanted to post an answer for others in my situation.

I have a solution running a ASP.NET Web Application with multiple other C# class lib projects.

My ASP.NET Web Application wasn't using json, but other projects where.

This is how I fixed it:

1. I made sure all projects where using latest version (6) using NuGet Update on all projects currently using any version of json - this didn't fix the issue
2. I added json to the web application using NuGet - this fixed the issue (let me dive into why):

Step 2 was first of all adding a configuration information for json, that suggest that all projects, use the latest version (6) no matter what version they have. Adding the assembly binding to Web.Config is most likely the fix.

However, step 2 also cleaned up som legacy code. It turned out we have previously used an old version (5) of json in our Web Application and the NuGet folders wasn't deleted when the reference was (I suspect: manually) removed. Adding the latest json (6), removed the old folders (json v5). This might be part of the fix as well.

Rigi

Answer 11

Veverke mentioned that it is possible to disable generation of binding redirects by setting AutoGEneratedBindingRedirects to false. Not sure if it's a new thing since this question was posted, but there is an "Skip applying binding redirects" option in Tools/Options/Nuget Packet Manager, which can be toggled. By default it is off, meaning the redirects will be applied. However if you do this, you will have to manage any necessary binding redirects manually.

Maramarabel