Unity Technologies is migrating to .NET Core, a move that will bring modern .NET to Unity developers and also promises to enhance the technology for .NET developers in general.
In a post this week, Unity’s software team said it has embarked on a “multiyear initiative … to migrate from the Mono .NET Runtime to CoreCLR, the modern .NET (Core) Runtime.”
The Unity game engine is used by more than 50% of games across mobile, PC and consoles according to the company. The engine is written in native code but can be scripted using C#, forming a large community of C# developers. The version of .NET used in Unity though is based on .NET in its cross-platform Mono form, rather than .NET Core.
Unity developers have complained about lack of access to new C# features and performance improvements, as well as non-standard approaches to areas such as asynchronous coding and package management. Part of the problem lies with the Unity runtime API, rather than with .NET itself, and the constraints it places on interop code.
That Unity has fallen behind in this way may seem odd, since the company has been a critical element in the progress of .NET from Windows-only to a cross-platform runtime.
Unity was an early adopter of Mono, to the extent that without it the open source implementation of .NET would have progressed more slowly or perhaps not have survived. That legacy has become something of a burden though. At GDC (Game Development Conference) 2022 earlier this year, VM Team Lead Josh Peterson explained how Unity became closely tied to the Mono runtime, preventing migration to the .NET Core CLR (Common Language Runtime), and developed its own package manager and .asmdef package definition files, and does not use MSBuild, the .NET build tool.
Even the Mono runtime is a fork of the official version. The consequence is that people who have learned .NET elsewhere find that in Unity they cannot use familiar tools, or C# language features like async and await statements for asynchronous coding.
Another big issue is that Mono has an embedding API that does not exist in .NET Core. The way this works is that the Unity native C++ application hosts the .NET runtime. In order to overcome this, Peterson said that Unity is “implementing the Mono embedding API on the .NET Core CLR” and that this work will be submitted to the open source .NET project so it is available to all.
The team has had to solve some tricky problems, he said, in the area of native code interop, and has written its own marshalling layer to overcome issues such as managed code objects that may move to different memory locations and break native code that references those objects.
The intent is to bring Unity’s work on .NET into the mainstream. “We need to make sure that we’re not building our own solutions … building on top of, instead of forking,” said Peterson.
The migration is already under way but is complex. It begins with support for .NET CoreCLR on desktop platforms, expected in 2023, following which “we’ll be porting the Unity Editor to .NET CoreCLR and removing support for the .NET Mono runtime at the same time,” said the team, with this new editor expected in 2024.
Unity’s move has been welcomed by game developers though there will still be limitations. Asked whether Unity will be decoupled from specific .NET versions, Peterson said in a post that “the .NET version will be tied to the Unity version very much like it is today … it is pretty tightly coupled to the .NET runtime.”
There will also be breaking changes for existing code, and the lengthy time for the migration is another source of frustration.
All that said, Unity remains important to the .NET ecosystem and having it feed more fully into the wider .NET ecosystem will be helpful for a project that in some ways remains dominated by Microsoft’s platform and has struggled to attract a wider community of developers.