[Bug] "Could not load file or assembly" when using third-party libraries

[applejag]

Thank you for your hard work.

I have problem with this package when I try to plug google.apis.sheets.v4 with Unity 2019.2.13.

Error: Could not load signature of Google.Apis.Auth.GoogleJsonWebSignature+<>c:<GetGoogleCertsFromJson>b__16_0 due to: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. assembly:Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed type:<unknown type> member:(null) signature:<none>

• google.apis.sheets.v4 is latest v4.1.42.0.1791 with proper dependencies acquired via nuget. its dependency chain includes newtonsoft.json >= 10.0.0.2
  (And this is the point I don't get it why higher version is not working)
• Api Compatibility Level - unfortunately both 4.x / 2.0 fails with your package
• IDE reports zero problem, confirmed References, even build was succeeded
• But in Unity, same error occurs and unloads broken Google.Apis.Core and Google.Apis.Auth

The only solution that worked I found was;

• Use .NET 2.0 for every google DLLs
• Use Newtonsoft.Json.10.0.2 for .Net 2.0 from NuGet
• At least Unity Editor working flawlessly
• Both Api Compatibility Level 2.0 and 4.x are working

Since working dll is untouched, I guess I would face AOT problem later.
I wonder if there's any workaround or backport / net2.0 support may solve this problem.

Thanks again for your time and effort.

Originally posted by @tsweeper in #16 (comment)

[applejag]

@tsweeper Thanks for the compliment ^^

This is a very problematic issue that keeps coming back. It seems like it's a common enough use case.

The issue here is what I believe is both related to versioning AND strongly named assembly.

About the versioning: the compiler doesn't check the NuGet package info to see it can use a higher Newtonsoft.Json version. It's the NuGet package manager that looks at that info when it's searching the registry for a suitable match, and sometimes sets up a binding redirect. I am uncertain if that is possible in Unity. Maybe. If so then it would be a great solution for even the Strongly Named Assembly issue.

About the Strongly Named Assembly: the PublicKeyToken=30ad4fe6b2a6aeed part of the reference you see in the error message comes from a private key that JamesNK currently holds for himself. It's used to generate a signature on the DLL so the linker can distinguish between "fake and real" packages. The Strongly Names Assembly procedure give a lot more better benefits than seeing if the one who compiled had the key or not, but that's the biggest property in this context and arguably even an obstruction.

As for solutions, I am scouting multiple directions to solve this.

Closing due to duplicate of #7. Please comment if you have anything on your mind regarding this issue.

[Zurigan]

Having the same problem with the same Google Sheets package. From reading the other issues it sounds like the only fix for this would be a backported 10.x Newtonsoft.Json-for-Unity which is still in the works. Please correct if wrong, very frustrating trying to make these two coexist! :)

[applejag]

@Zurigan Yea totally hear ya!

I am slowly getting there but there are lots of balls in the air right now. We will make this pleasant in the near future, but excuse the delay in the meantime.