I’m trying to upgrade a project so I can look at using UIElements in 2020.1. Upgrading from 2019.3 which is a fairly recent release.
Having difficulties though with certain libraries I’m using in the new version and am confused as to why they are erroring out when I’ve not seen any mention of any major scripting backend change.
One such error:
Assembly 'Assets/Plugins/GoogleSpeech/GoogleSpeech/Google.Api.Gax.dll' will not be loaded due to errors:
Google.Api.Gax references strong named Newtonsoft.Json, versions has to match. Assembly references: 11.0.0.0 Found in project: 10.0.0.0.
Now I understand the error is in relation to my version of Newtonsoft.Json I’m using. What I don’t understand though is I’m using the exact same libraries in 2019.3 but it loads the libraries fine.
I think Unity also uses its own version of Newtonsoft.Json. If it’s upgraded in 2020.1 and you just so happened to strongly reference the old one through that Google library that would explain why it’s broken now.
In regular .NET you could play around with redirects but I don’t know if that part was ever implemented in Unity. Alternatively you can hack the Google DLL so it references the newer version and see if it works.
So worked this out that actually the libraries would run at runtime with no issue. The libraries have always been out of version but it seems this version of Unity is trying to validate more libraries more stringently.
I’ve raised it as a point of clarification with Unity mainly because users upgrading from previous versions of Unity could go down the same thoughts as I did and thought something major had changed in the development environment. A warning message is still good but perhaps with an indication to the developer to test at runtime if it has worked in previous Unity versions.
I thought this came from .NET when I initially encountered this thread so I double-checked and it looks like that this is indeed something Unity specific. You can tell by the bad grammar: “versions has to match.”
Hi guys, so the reason we added the validation is to give some better information, and also guard for not getting runtime errors. Strong Named(signed) assemblies that’s referenced need to match 1:1 with Versions.
So when Mono resolves types, it will look for a type in that version, if its not found, you would get a runtime error.
The validation added was intended to give better information of what versions Mono would search for, and also guard so one would know that this could result in runtime errors.
That said, Mono have a bug where assemblies in same folder, would not have Version validation, it would just load it anyway.
Given the response in this thread, and @bdovaz - we’ve changed the validation. Since Mono don’t care about assemblies in the same folder, we have removed the validation when that is the case, since it will currently not give any runtime errors.
So to sum up, Assemblies in same folder will not any longer give this error. Assemblies in multiple folders, with incompatible versions, we will show the error.
For solving the latter problem, we need to solve it by using something like bindingsRedirect. We are not currently working on that but have it on our todo. Its something we need to solve before Mono would fix the bug
@HaraldNielsen As I said in the other thread in 2020.1b it only works unchecking “Validate References” if it’s in the same folder. On different folder it doesn’t work even If I uncheck “Validate References”.
In 2019.3.x disabling that checkbox did work even if they were in different folders.
The way I understand that checkbox, by deactivating it I should be able to get the behavior of 2019.3x, right? That has changed in 2020.1b and it is a clear regression.
If the assemblies is in the same folder, and you uncheck “Validate References” it should go back to the same behavior as before. If you get type load failures and the assemblies is in same folder I would love a bug report to see the repo. But AFAIK we didnt upgrade or change Mono in any of those releases
To clarify I hadn’t ever needed to uncheck “Validate References” in 2019.3 and I had no errors. Is that behaviour meant to be the same in 2020.1? All my libaries are in the same folder (except for runtime specific libraries for specific platforms).
The validation we added is before trying to load the assembly into the C# Domain. The reason we added that is because Mono will give runtime errors when not finding types when a dll is not added/found where that type is, and sometimes even crash. Mono resolves the types lazy, so when it hits the codepath will it resolve it.
What you are seeing there is one of the Runtime errors from Mono and is not part of the Validation
So my question is, does anything you’ve done help me remove that error? Or do I have to wait for the solution of the bindingRedirects that may be a year (or more) late? It’s really blocking us.
@bdovas sorry to say that nothing done yet has solved the issue where assemblies is in different folders.
We have discussed bindingRedirects internally aswell, since newer mono versions also is more strict with AssemblyVersions. So we need to address this for that as well.