Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Unity 2020.1 changes to .Net version?

Discussion in '2020.1 Beta' started by Virtimed, Apr 16, 2020.

  1. Virtimed

    Virtimed

    Joined:
    Nov 1, 2017
    Posts:
    27
    Hi,

    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:
    Code (CSharp):
    1. Assembly 'Assets/Plugins/GoogleSpeech/GoogleSpeech/Google.Api.Gax.dll' will not be loaded due to errors:
    2. 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.

    What change in 2020.1 would cause such a problem?
     
    Virtimed, Apr 16, 2020
    #1

  2. runner78

    runner78

    Joined:
    Mar 14, 2015
    Posts:
    727
    Check the Package manager, "Newtonsoft Json" exsts also as package. But this package use version 12.
     
    runner78, Apr 17, 2020
    #2

  3. Virtimed

    Virtimed

    Joined:
    Nov 1, 2017
    Posts:
    27
    I supply Newtonsoft.Json myself so that shouldn't be the problem and it's not listed as a package in the package manager
     
    Virtimed, Apr 18, 2020
    #3

  4. Awarisu

    Awarisu

    Joined:
    May 6, 2019
    Posts:
    215
    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.
     
    Awarisu, May 1, 2020
    #4

  5. rastlin

    rastlin

    Joined:
    Jun 5, 2017
    Posts:
    127
    Lorash is correct.

    Your best bet is to recompile Google.Api.Gax yourself and reference version 10.0.0.0 of Newtonsoft.Json.

    As far as I know there is no way to define binding redirects in Unity for .net code.
     
    rastlin, May 4, 2020
    #5

  6. Virtimed

    Virtimed

    Joined:
    Nov 1, 2017
    Posts:
    27
    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.
     
    Virtimed, May 5, 2020
    #6

  7. Awarisu

    Awarisu

    Joined:
    May 6, 2019
    Posts:
    215
    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."
     
    Awarisu, May 6, 2020
    #7

  8. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    988
    bdovaz, May 6, 2020
    #8
    Awarisu likes this.

  9. Virtimed

    Virtimed

    Joined:
    Nov 1, 2017
    Posts:
    27
    Virtimed, May 6, 2020
    #9

  10. HaraldNielsen

    HaraldNielsen

    Unity Technologies

    Joined:
    Jun 8, 2016
    Posts:
    131
    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, May 13, 2020
    #10
    phobos2077 and bdovaz like this.

  11. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    988
    Looking forward to that bindingsRedirect solution.
     
    bdovaz, May 13, 2020
    #11

  12. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    988
    @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.
     
    bdovaz, May 14, 2020
    #12

  13. HaraldNielsen

    HaraldNielsen

    Unity Technologies

    Joined:
    Jun 8, 2016
    Posts:
    131
    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
     
    HaraldNielsen, May 14, 2020
    #13

  14. Virtimed

    Virtimed

    Joined:
    Nov 1, 2017
    Posts:
    27
    That's exactly what I had
    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).
     
    Virtimed, May 14, 2020
    #14

  15. HaraldNielsen

    HaraldNielsen

    Unity Technologies

    Joined:
    Jun 8, 2016
    Posts:
    131
    If your libraries is in the same folder, the behaviour should be the same from now on as you see in 2019.3, in the upcoming 2020.1.0b11 release
     
    HaraldNielsen, May 27, 2020
    #15

  16. Virtimed

    Virtimed

    Joined:
    Nov 1, 2017
    Posts:
    27
    Ok thanks!
     
    Virtimed, May 28, 2020
    #16

  17. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    988
    @HaraldNielsen I see the following in 2020.1b10:

    I installed 2019.3.15f1 and I see a problem that I think it occurs in both 2019.3.x and 2020.1bx.

    Even if you remove the checkbox from "Validate References" it still fails (being on different folders) because of errors like this:

    Didn't you say that if we deactivated that checkbox we could "skip" that validation?
     
    bdovaz, May 29, 2020
    #17

  18. HaraldNielsen

    HaraldNielsen

    Unity Technologies

    Joined:
    Jun 8, 2016
    Posts:
    131
    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
     
    HaraldNielsen, Jun 8, 2020
    #18

  19. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    988
    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.
     
    bdovaz, Jun 8, 2020
    #19

  20. HaraldNielsen

    HaraldNielsen

    Unity Technologies

    Joined:
    Jun 8, 2016
    Posts:
    131
    @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.
     
    HaraldNielsen, Jun 9, 2020
    #20
    bdovaz likes this.

  21. bdominguezvw

    bdominguezvw

    Joined:
    Dec 4, 2013
    Posts:
    96
    Any news on this? We also need this.
     
    bdominguezvw, Jul 14, 2020
    #21
    bdovaz and phobos2077 like this.