Creating a NuGet package that includes other Nuget Packages - NewtonSoft Reference Errors - visual-studio

Question

Getting started with creating NuGet packages for various common libraries, that were up to now typically added as a project to a solution.
Using TFS 2017 to build and deploy the NuGet packages to the Package Manager built into TFS 2017.
I have an issue with dependencies and don't fully understand how to resolve it. It's also a little complicated to detail; so here goes.
I have built a class library that has a NuGet package installed - The package is SharpRaven 2.2.0
SharpRaven has a dependency on NewtonSoft.Json >= 6.0.8
This results in Newtonsoft.Json being added to my class library. By default NewtonSoft.Json 6.0.8 is installed.
I then package up my class library as a NuGet package - Called it TestNuGet
TFS is building the nuget by using the .csproj file and not the nuspec
When I use this new package in projects I see there are dependencies for SharpRaven and Newtonsoft (if neither of those are currently installed in the project).
My problem starts with Newtonsoft.Json.
Take the following projects:
Solution A and B
- Already has Newtonsoft 9.0.1.
- Install TestNuGet, so SharpRaven is also added
- Project is fine, no errors when using TestNuGet
Solution C
- Already has Newtonsoft 9.0.1.
- Install TestNuGet, so SharpRaven is also added
- Errors when calling TestNuGet; error below:
Solution C
- Remove Newtonsoft 9.0.1
- Install TestNuGet, SharpRaven and Newtonsoft 6.0.8 installed
- Project is fine. No errors
- Update Newtonsoft
- Get Errors again as before
If i update NewtonSoft to 9.0.1 in TestNuget and rebuild it I get exactly the same issues above.
There are no projects within Solution C that are referencing anything other than 9.0.1.
It seems to me that when adding a NuGet package NuGet looks at all of the packages within and uses those dependencies, ignoring what is already added to the TestNuget.
So the question, i think - Is there a way to instruct nuget to use the newtonsoft version i added to TestNuget and to not try and meet the dependency sharpraven is calling for? Something to add to the Packages.config perhaps?
Would I be better using a nuspec file? is there more that can be set in this to control how the package is built?
Or is there something I'm missing in my usage of these packages.
Error being thrown when trying to use the package is:
Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.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)
Binding Redirect from the web.config of the solution that will not run looks as this:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-9.0.0.0" newVersion="9.0.0.0" />
</dependentAssembly>
I also tried adjusting the redirect to encapsulate 9.0.1
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-9.0.1.0" newVersion="9.0.1.0" />
</dependentAssembly>

Answer 1

The issue here is that an assembly has a reference to a version 6 of NewtonSoft.Json which is not found at runtime since only a higher version is present.
This is usually worked around with binding redirects. NuGet should automatically generate the necessary binding redirects into runnable (exe, web apps) projects using packages.config when installing packages.
For PackageReference based projects it is sometimes (test projects, plugin-library, …) required to also tell msbuild to automatically generate the needed binding redirects based on the resolved assemblies. This can be done by adding this to the csproj file:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
However this does not protect against actual breaking changes that could have occurred in new major versions of a library.
Also note that these binding redirects may be overwritten by the binding redirects of other applications re-using the built assembly (parent projects, plugin-system etc).