Hello Everyone,
As Unite 2024 is underway, where we’re showcasing the latest in Unity 6, we also wanted to take this opportunity to share an update on the next generation of Unity and the .NET Modernization efforts we’ve been working on over the past few years. Please note that the .NET Modernization is not part of Unity 6. In our previous updates from May 2024 and August 2024, we highlighted some key milestones. Now, it’s a good time to recap what’s been achieved and give you a look at what’s coming in Unity next.
The .NET Modernization is composed of the following initiatives:
- .NET 8+ CoreCLR Migration
- Burst Integration
- MSBuild Integration and Convergence
- From Domain Reload to Code Reload
While these initiatives are unlocking new possibilities, one of our main goals remains improving iteration time in the Editor. Our team is focused on leveraging .NET 8+ capabilities, with other Unity teams also contributing to this optimization. We’re working towards making script changes faster and smoother.
.NET 8+ CoreCLR Migration
A big part of our CoreCLR integration has been ensuring proper garbage collection (GC) and memory management. With Mono, we assumed that managed objects were pinned in memory, which isn’t the case with CoreCLR. This meant we had to adjust how we use GCHandle in native code, allowing the GC to move objects during memory relocation. While this migration work is mostly complete, there are still optimizations to be made to ensure CoreCLR performs as well as Mono. Several teams are already ramping up to address these challenges.
We’re also working to unlock full .NET 8 API access across Unity. This is a big step forward, given all the new APIs and optimizations since .NET Framework. This will offer Unity developers significant benefits, including:
- JIT Compiler and GC improvements
- Reduced allocations and more Span-based APIs
- .NET Hardware Intrinsics support
- Several new APIs and performance improvements across the board
We’re extending .NET 8 support to IL2CPP across all major platforms. Initially, we’re bringing the .NET 8 BCL to core platforms, with plans to expand this over the next few months. Later, we’ll work on optimizing IL2CPP with .NET hardware intrinsics support and addressing the increase in C++ code generation as more .NET code is written in C#. IL2CPP will continue to rely on the Boehm GC.
Another advantage of this standardization is that it ensures our integration of .NET 8 CoreCLR will allow us to easily switch to future versions of .NET. .NET 9 is coming soon - with its own set of optimizations, and we plan to move to it! The same goes for .NET 10 next year. Our goal is to get the latest .NET features into your hands as quickly as possible.
Burst Integration
Burst is becoming a central part of the Unity Editor and Engine. Previously, Burst was available only as a package for user projects, but now we’re integrating Burst directly into Unity. This is especially important as other teams work to make ECS fully interoperable with GameObjects.
We’re also adding .NET 8 Hardware Intrinsics support to Burst. This will allow Burst to take advantage of the latest CPU features, optimizing your code and supporting standard .NET 8+ SIMD libraries — similar to what we’re doing for IL2CPP.
MSBuild Integration and Convergence
We’re making progress on fully integrating MSBuild between Unity’s internal build pipeline (for UnityEngine modules) and the user code compilation pipeline. This convergence will lead to a more streamlined and optimized workflow.
A key benefit of MSBuild integration is an improved IDE experience. In the past, building from the IDE didn’t use the same compilation pipeline as Unity, which could lead to inconsistencies. With MSBuild integration, we’ll share the same pipeline, ensuring the IDE build process is reliable.
MSBuild will also bring a major upgrade by standardizing the C# compilation pipeline, including support for NuGet packages. Another advantage is the extensibility of MSBuild, allowing developers to customize the managed code build process more easily.
Code Reload
As we’ve mentioned before, Code Reload is replacing Domain Reload, which represents a significant shift for Unity. Instead of reloading the entire domain, Code Reload will only refresh the user code that has changed. This promises a much faster workflow when updating scripts. We’re in the process of moving Unity assemblies and packages to Code Reload so they stay persistent when user code is updated.
However, user code will need to work cooperatively with the Editor. For example, in the case of a code reload, threads started by user code must terminate and restart properly, and GCHandles created by user code will need to be freed and recreated.
Existing APIs were limited when it came to handling reloads or entering play mode correctly. We’re introducing a new set of lifecycle APIs to help user code handle these events properly. These APIs will be based on C# attributes, making it easier and more robust to subscribe and unsubscribe from these events.
Closing Remarks
As you can see, we’ve made solid progress across several areas, but there’s still more to do as we work to deliver the best scripting experience in Unity.
While we can’t provide specific timelines, rest assured we’re fully committed to these efforts. Please continue asking questions and sharing feedback!
Best regards,
Alexandre Mutel & the .NET Tech Group at Unity