Search Unity

  1. Unity 2018.3 is now released.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We've updated our Terms of Service. Please read our blog post from Unity CTO and Co-Founder Joachim Ante here
    Dismiss Notice
  4. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  5. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

A question about the Scripting Runtime Version and API compatibility

Discussion in 'WebGL' started by Nirag, Jan 10, 2019.

  1. Nirag

    Nirag

    Joined:
    Dec 19, 2018
    Posts:
    8
    Hi everyone!
    I'm having some strange issues with loading a Unity game built in WebGL on a site. The file uploading process goes smooth, no problems at all, but the behaviour of the file becomes erratic after that. After uploading it, the game loaded perfectly. The following day, I tried to load it again, and it didn't work, showing a couple of errors. The day after I tried again, and the game worked correctly again. It seems like these errors are showing randomly, for I don't know what the reason could be.

    Looking into the Player menu of the Build Settings, I've noticed that the Scripting Runtime Version is set to ".NET 3.5", and the API compatibility version is set to ".NET 2.0 Subset". These were set as default, and I built the entire game with those settings. However, while looking for the possible cause of that erratic behaviour, I found the Unity Manual page that describes the Scripting Runtime Version and the API Compatibility, and it's stated that both .NET 3.5 and .NET 2.0 Subset are "deprecated".

    What does "deprecated" mean? Does it mean that using those versions may cause problems?
    If yes, can i safely change both the Scripting Runtime Version and API Compatibility to other, non-deprecated versions, or I might cause some issues?

    Thank you!
     
  2. kognito1

    kognito1

    Joined:
    Apr 7, 2015
    Posts:
    237
    It was just deprecated in 2018.3. It means Unity will be removing support for it in the (near?) future and probably won't "try that hard" to fix any bugs with it in the meantime.

    We switched to the new compiler when we moved to 2018.3. I'd say in general it "just works" but we did have a few bugs with it (one showstopper that Unity resolved in a 2018.3 beta, others we worked around). As a positive, with stripping set to "High" the new compiler did seem to produce a slightly smaller binary!
     
  3. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    24,195
    Anything depreciated means you should now begin replacing the depreciated bits. If you do not then it will eventually be removed from the engine and you will have to replace it later if you intend to upgrade.

    It's a heads up that it WILL be removed, and usually they will make sure there is an equivalent (typically a depreciation in Unity means about 10 mins of work to fix, today, for any dev).
     
  4. Nirag

    Nirag

    Joined:
    Dec 19, 2018
    Posts:
    8
    Thank you for the explanations!
    If I switch to another Scripting Runtime Version (i.e. .NET 4.x), will it affect my project? Can a late switching cause problems? (I'm saying "late" because my project is finished, I realized all of this when I was checking the Player menu in the Build Settings).
     
  5. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    24,195
    Switching to Net 4.x should have zero effect except be better and faster in some cases. You get more features as well.

    In this case 10 mins becomes 10 seconds I guess, really hard work :D
     
  6. Nirag

    Nirag

    Joined:
    Dec 19, 2018
    Posts:
    8
    Thanks!
    So, to switch to NET 4.x, do I only need to change it in the Player menu and restart Unity, or are there additional steps I should take?
     
  7. JJJohan

    JJJohan

    Joined:
    Mar 18, 2016
    Posts:
    131
    Nope, that's all there is to it. I'd recommend sticking to the .NET Standard profile under the 4.x Runtime unless you require the extra APIs. Basically means less code that needs to get stripped during build time.
     
  8. Nirag

    Nirag

    Joined:
    Dec 19, 2018
    Posts:
    8
    Thank you! You mean selecting .NET 4.x as Scripting Runtime and .NET 2.0 Standard as API compatibility level, right?