Search Unity

Unity 2018.1 beta now includes a fully-supported, modern .NET runtime. As the .NET ecosystem continues to evolve, Unity is committed to maintaining feature compatibility with the latest and greatest in the .NET world.

How did we get here?

In Unity 2017.1, we shipped the first experimental preview of the stable scripting runtime. Throughout the 2017.2 and 2017.3 release cycle, many Unity users worked with this experimental scripting runtime and provided invaluable feedback (thanks, everyone!). We’ve also worked closely with excellent developers from Microsoft, both on the Mono and Visual Studio teams. As we’ve sorted out issues and corrected bugs, the modern scripting runtime has become more and more stable. In 2018.1 we feel it is ready for widespread use. So if you’ve not tried it yet, please do so now!

Why should I try it?

The stable scripting runtime brings a number of modern C# and .NET features to Unity. Specifically, you’ll get access to:

  • C# 6
  • The .NET 4.7.1 class libraries
  • Support for assemblies built against .NET Standard 2.0 and 1.x
  • Managed code debugging with IL2CPP (experimental in 2018.1 for standalone players, expect full support in the next few releases)

What .NET Profile should I use?

The stable scripting runtime comes with two new .NET profiles. A .NET profile defines the API surface your code can use for the .NET class libraries. You can choose the .NET profile for your player build via the “Api Compatibility Level” option in the Player Settings. The two .NET profiles Unity supports are

  • .NET Standard 2.0
  • .NET 4.x.

The .NET Standard 2.0 profile matches the profile of the same name published by the .NET Foundation. This is a great profile to choose for a new Unity project. It is smaller than .NET 4.x and we recommend it for size-constrained platforms such as mobiles. In addition, we’ll make sure this profile works on all platforms Unity supports. If you are a developer of libraries used with Unity, this is the profile you want to target.

The .NET 4.x profile provides access to the latest .NET 4 API. This includes all of the code available in the .NET Framework class libraries. It also supports all of the .NET Standard 2.0 profiles, so it will work with managed plugin assemblies built against .NET Standard 2.0. While it provides access to a large API, some parts of that API will not work on all platforms. If your project requires functionality not exposed in .NET Standard or has legacy code, this may be a good option.

What does the future hold?

Now that the modern scripting runtime is fully supported, we’re committing to maintain it for all future versions of Unity. We’re also working on TLS 1.2 support across all platforms and improvement in build size and build times with the modern scripting runtime.

The legacy scripting runtime will remain the default for new projects in 2018.1. During the 2018.x release cycle, we will change the default scripting runtime for new projects to be the stable scripting runtime. We will deprecate the legacy scripting runtime, although it will be fully supported for existing projects.

We are aggressively working to remove the legacy scripting runtime, and make the stable scripting runtime the only option. We recommend all users start the process of migration to the stable scripting runtime soon. As our focus shifts to the stable scripting runtime, we limit the bugs fixed in the legacy scripting runtime. Additional guidance will follow about the deprecation and removal schedule for the legacy scripting runtime.

At Unity, we’re excited about the recent evolution of the larger .NET ecosystem. As it continues to improve we’re dedicated to bringing the latest .NET tools to Unity developers, like C# 7, so stay tuned!

We’re looking forward to discussing our runtime upgrade and upcoming scripting features in this corner of Unity Forums!

32 Comments

Subscribe to comments

Comments are closed.

  1. Kenneth Christensen

    April 10, 2018 at 9:44 pm

    Does the 4.x runtime mean that we can access TLS1.2 https endpoints ?

    1. No, we still don’t support TLS 1.2 in the Unity 2018.1 release. However, Unity 2018.2 does support TLS 1.2 for all platforms with the .NET 4.x runtime.

  2. I would love to use, it. Unfortunately unit tests do not work with .Net 4.6 in command line. see this bug:
    https://issuetracker.unity3d.com/issues/dot-net-4-dot-6-scripting-runtime-unity-executable-hangs-when-running-tests-in-batchmode

    It has been stuck for months in “Fixed in future release”.

    1. I’ve just checked on this. The fix was back ported to 2018.1, so it should be corrected in the latest 2018.1 beta release.

  3. What’s the chance of getting a new fresh for code files, with hooks for Rider/Visual Studio, so we can build there, and not have to build again in Unity? Can you guys at least bare that in mind as you go forward with this solution..

    Edit in a good code editor + compile again == crappy experience – seems like a good time to fix that, perhaps.

    :)

    1. Josh Peterson

      April 5, 2018 at 1:44 pm

      I don’t follow your request, sorry. Could you elaborate a bit more? Maybe this his something better discussed on the forums.

  4. vscode debugging still doesn’t work with .NET 4.6. 1. Editor freeze after debug detach. 2. Type names are displayed with whole namespace chain (which makes them unreadable). 3. Breakpoints placed before debugging are not caught. 4. We can’t watch class variables values (they work only if written as this.variableName). These bugs are reported since august 2017. Of course, we could use VS community, but it’s way worse than code. VSCode is way faster, has better intellisense and its source is released with MIT license (we can’t use VS community in our work, because of community license).

    1. I don’t see that we have an open bug on VSCode debugging. Can you let me know the bug number or open a new bug report?

      1. When we tried to report them, they were marked as duplicates, and we got link to vscode-unity-debug github issue tracker. It’s full of .NET 4.6 issues, so we stopped reporting them through bug reporter.

      2. Case 944169

        1. Thanks for the information. I’ll check with our code editors team to see how we should handle this.

  5. This is fantastic news! I am a editor tools developer and I was wondering if the editor itself still runs on the 3.5 run-time? Is there any way for me to leverage the new .NET 4.x profiles without having my consumers switch to them?

    1. The editor runs with either the old or the new runtime, depending on the user’s option chosen in the player settings. You can use the NET_4_6 define to use code that should only run with the new scripting runtime. See this page for more details: https://docs.unity3d.com/Manual/PlatformDependentCompilation.html

  6. Is .net core on the radar for the future at all?

    1. It is not something we’re looking at for the near future, for a few reasons. First, it does not have a full embedding API, as Mono does. Second, it does not support enough platforms currently. We have done some experiments with it though, so I can’t rule it out entirely. But we’re focused on other priorities at the moment, like build size, iteration time improvement, GC, and C#7.

  7. Could you tell us what this means for garbage collection? Is generational GC part of the new runtime?

    1. The upgrade of Mono means the GC engine changes to SGen, which is generational, http://www.mono-project.com/docs/advanced/garbage-collector/sgen/

    2. Jonathan Chambers

      March 29, 2018 at 1:37 am

      The new Mono does have SGen as an option, but Unity is still using Boehm for now. Migrating to SGen requires additional work on Unity.

      1. I wonder what problems you encountered which don’t allow you to switch GC to SGen?

        1. Plenty of native code in Unity Engine has unfettered access to managed memory. This is fine for a conservative, non-moving GC. A moving GC could cause problems for that code. We’re actively working on locking down access to managed memory from our native code so that we can support a different GC in the future.

        2. Yea, I see now. Keep it going! SGen has much lower latencies than Boehm GC which is crucial for games.

  8. Null propagators here I come!

    1. Indeed – I’ve been using them in Unity since 5.6, or since when they had experiemntal support… which is why I know, BE CAREFUL with monobehaviour and gameobject. They both override == to allow you to write those ghastly javascript-esque if statements i.e if (!myGameObject) instead of if (myGameobject != null)..

      Point being – the null propagation will cause Null Pointer Exceptions at Runtime.

      I had to refactor a couple of 100 of those in my codebase before I worked it out.

      Other than that, enjoy – it’s glorious for sure :)

      1. Alkis Tsapanidis

        March 29, 2018 at 12:29 pm

        Actually, they override it so that people do not need to check whether the object is alive in C++ land as well as null checking the pointer to it. The implicit bool cast is separately implemented:

        public static implicit operator bool(Object exists)
        {
        return !CompareBaseObjects(exists, null);
        }

        For more info:
        https://github.com/Unity-Technologies/UnityCsReference/blob/11bcfd801fccd2a52b09bb6fd636c1ddcc9f1705/Runtime/Export/UnityEngineObject.bindings.cs

  9. Pra Pangurakan

    March 28, 2018 at 9:33 pm

    Thank you Unity for .NET Standard 2!

  10. Very good news. How come c# 7 is not supported?

    1. Jonathan Chambers

      March 28, 2018 at 10:11 pm

      We have not yet migrated to Roslyn which is a prerequisite for supporting C# 7.

  11. Ah, thank you. Finally, we can forget about back-porting libraries to the obsolete .NET 3.5 API and start using the original packages directly from NuGet. Support for .NET Standard opens the doors to modern and lovely .NET stuff.

    Looking forward for more updates in this direction.

    1. Patrick McCarthy

      March 28, 2018 at 10:21 pm

      This will definitely help to make many more NuGet packages compatible with Unity.

      NuGet For Unity will absolutely support these new profiles.
      https://assetstore.unity.com/packages/tools/utilities/nuget-for-unity-104640

  12. Love it! Down with the past. Bring on the future!

  13. awesome work, keep it up!

    1. +1