CoreCLR and .NET Modernization - Unite 2024

Unity Engine
, , ,
1

Hello Everyone, :smiling_face:

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

76 Likes
3

My mood suddenly become totally disappointed at here

Again? Even with unite we still stuck on this word. Even with Unity 6 we still can’t have true dotnet and everything is still picture of carrot ever again

14 Likes
4

Keynote presentation mentioned open beta in 2025. Shouldn’t be too far off.

5 Likes
5

I am currently watching keynote so I don’t actually know the full detail but if the wording is can’t provide specific timelines it more likely that this feature are not guarantee to be include in beta

And historically I recall this word had been used every year for 4 years. So if it still this word it can be extended another 4 years until this word no longer been used

I can’t have hope

1 Like
6

We do have something planned for next year, but we can’t give a specific date yet. But, CoreCLR is definitely going to be in the beta. It’s a key part of the foundation for Unity next, and everything else will depend on it.

It’s not about trying to keep things secret or giving out vague corporate statements. The reality is that our engineering teams genuinely don’t know the exact dates yet because we have still significant challenges ahead.

37 Likes
7

I really want to be optimistic. But, you see, we even skip the whole unity 2023 and we need to change unity 2024 into unity 6. Which is even now still in preview. We don’t have touched the new unity’s CoreCLR even once ourselves. Only selected few have access it and we don’t really know the real situation. I also totally understand the challenge but if it was all this time and you still have enough challenge to made release date undetermined, It only indicate that unity 6.1 may be so far out of reach

It’s not like we have beta with coreclr in our hand already and the unite was announce that unity will fully release it in October. This unite still show only the teaser again while the first blog post about this work was 912 days ago

I don’t want to think that the only reason I stay with unity just be a sunken cost fallacy, but it seem likely as long as the new project I made is not CoreCLR while it was already being used by godot and stride (even unreal had plugin for it, indicate that unreal is totally extensible)

8

I’m using Unity because it is head and shoulders a better engine with a more complete feature set like prefabs and portability to a range of platforms while still having competitive graphics and animations.

Godot may have received these updates sooner, but it’s also a much slimmer platform still in its infancy so of course it will receive these updates faster.

I’m not currently using Unity because of “Sunk Cost” I’m using it for the same reason it’s a bit more difficult to expand on, because it’s a complicated tool with lots of amazing features.

2 Likes
9

CoreCLR seems to be part of Unity 6.1, which is coming April 2025.

1 Like
10

Definitely not. As I explained at the very beginning of my post above, CoreCLR is not part of Unity 6.

7 Likes
11

Awesome update @xoofx !

12

I totally want to believe that but the internal member themselves state that

can’t give a specific date yet

Ah, yes, confirmed there above me

13

Im happy with this news thanks for sharing

1 Like
14

We do have something planned for next year… CoreCLR is definitely going to be in the beta.

I usually stay far away from anything but LTS. However, I find myself looking forward to testing out the Unity 7 beta next year.

2 Likes
15

I think people are confused about the word beta. Some people understand it was unity 7 beta (which had no determined date). Some assume it would be 6.1 beta (which likely around April 2025)

Would you please also confirm which beta CoreCLR will be included?

1 Like
16

Given this is probably the biggest update Unity has/is going through, I’d rather wait until it’s all good and ready before it even sees the light of public. No point in them setting a timeline only for it to be pushed back.

6 Likes
17

Sounds like your needs are more theoretical rather than practical? What does CoreCLR provide that you so very much need right now? It, of course, would be a great boon to iteration speeds but besides that - what else?

Unreal’s C# extension won’t work on consoles. Godot doesn’t have native console support, you have to work with third parties unrelated to Godot Foundation to get your game on console and most of them don’t deal with C#, only GDScript. Stride can’t export to consoles and there are no plans for it afaik.

Unreal 5+C#, Godot C# and Stride can’t export to Web at all.

Engines like Godot and Stride don’t have Cinemachine equivalent. Don’t have rich Asset Store ecosystem. And have worse tooling in general be it profiling or even building. Godot will pack EVERYTHING that’s in the project no matter if it’s actually used in the built scenes or not.

People are not sticking with Unity due to sunk cost fallacy, they’re sticking with it because it’s a mature platform that ships professional games every day.

9 Likes
18

Oh okey, I saw this big tile on the bottom left saying Unity 6.1 and assumed all the tiles there are part of 6.1, I did not notice “next release gen”

image
image1920×1080 129 KB

Is there a way to sign up for the Alpha program of Unity 7?

5 Likes
19

Seem like we need to be very famous influencer or studio, the selected few that will have privilege to their club. Like around the time at runtime fee shenanigan only these nobles citizen been invited to consult and know the change before us mere plebeian

3 Likes
20

I could see a few things. Modern .NET has a ton of new features, better library support. It could even be the difference between making your project actually viable, say like the physics engines bundled aren’t good enough for your use case so you need an alternative. I can think of at least one

Bepu which relies so much on vectorization stuff unity doesn’t have that performance is abysmal. And even on code that isn’t like that, there is an order of magnitude or more performance increase in many cases.

1 Like