When using Nuget packages (strong named assemblies) we encounter this problem, the only logical way to solve this is through binding redirects.
Threads about this topic:
How is this going? @HaraldNielsen mentions that you have had conversations internally at Unity since it is also something you need.
Hi @bdovaz - Was actually just about to write to you guys about this.
I started working on this, and got bindingRedirect working locally. Will keep you posted
Thank you very much, @HaraldNielsen . I really appreciate your transparency and that you remembered to answer.
@HaraldNielsen I just saw on 2021.1a2:
“Scripting: Add option to disable Signed Assembly version validation. (1193928)”
Is this the final “solution”? It seems more like a workaround so you (Unity) don’t have to implement a better solution like binding redirects.
It confuses me because you said you have it working locally.
@bdovaz thx for pinging me!
tl;dr: Yes this is the current solution for this problem, until we have a better option 
I had bindingsRedirect working locally, with app.config and that sort. So the reason that we didnt go with a full bindings redirect solution is that we lack all the tooling you get fx by msbuild / visualstudio, where these things is normally generated. By that we had alot of internal discussion how to handle this the best way.
In short, you want to drag a assembly in, and have it working easily. Just like you would in nuget, you add a dependency, if it depends on differently compiled references it auto creates a app.config with the bindingsRedirect. Myselfs, I would not like to manage these xml files by hand, especially if I did not know about bindingsRedirect’s
So current solution is that we have this flag that will do it for you. We set a flag in mono that will handle the version validation for you.
In the long term we are also in talk of how to better incorporate the normal .Net tooling better, so we get more standardized way of solving such issues.
Let me know your thoughts!
As you can imagine, I was asking for a solution like binding redirects because as you say, the integration of Unity with the common tools in any .NET development are nonexistent . If we had a full integration of Nuget packages in the Visual Studio solution we would not have this problem. Or at least your colleagues ( @xoofx ) solution:
https://github.com/xoofx/UnityNuGet
I have also discovered this:
https://discussions.unity.com/t/814492
I don’t know if you are trying to do something similar to the development of @xoofx that would be quite ideal to integrate it into the UPM ecosystem because although integrating the Nuget support with the csproj it would be very well “separated” from the UPM world.
@bdovaz I agree and can imagine that we will support Nuget at some point.
UPM has been quite a trip for Unity and I think that not opening up for the Nuget registry in UPM early was wise since we didn’t even know all the details how our package story was going to be.
When you say “we will support Nuget at some point” you mean in the UPM world I suppose? Because if you have a Nuge dependency on a UPM package it should be automatically resolved and if that depenency is “outside” the UPM world it’s quite difficult to manage dependencies and more importantly, solve/merge different dependencies/versions.
This is just my personal opinion, but yes it should be part of UPM
@bdovaz would this help? Dependency On Newtonsoft.Json
Yes, it would, thanks!