Updated scripting runtime in Unity 2018.1: What does the future hold?

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!

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.

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).

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.

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?

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.

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.

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.

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.