CoreCLR, Scripting, and ECS Status Update - March 2026

@HaraldNielsen can you answer, please? Thanks

Yes more than these 4, and over time we also want to open up for the API for Users can define their own callbacks using the same system

2 Likes

Hi Bdovaz :slight_smile: Did you refer to the Enum question above?

If you look closely, in my message I was replying to a message I posted a few days ago.

But anyway, to sum it up, my question is whether it will be possible to install NuGet packages, use .editorconfig, and generally use the tooling just like in a normal .NET project.

No related announcement at this time. If and when that changes I’ll link it in this thread.

3 Likes

Can someone explain to me, when they mention CoreCLR for the Editor - Does that mean will see large performance improvements to working in the editor in general? Would love a snappier and smoother editor experiance.

3 Likes

You can use GitHub - bdovaz/UnityNuGet: Provides a service to install NuGet packages into a Unity project via the Unity Package Manager ¡ GitHub or GitHub - GlitchEnzo/NuGetForUnity: A NuGet Package Manager for Unity ¡ GitHub . I prefer the former.

That’s the long-term goal - and CoreCLR Editor is a necessary milestone to unlock that future - but in 6.8 alpha we’re shooting for performance parity.

1 Like

Fantastic! I know On my Mac I get some issues, a weird one where that can’t be fixed is the “Quality” Setting tabs in the project settings, scrolling up and down it lags like hell and it’s the only tab to do so, everything else so far so good.

Keen for general performance improvements, didn’t relise that CoreCLR would effect the Editor itself so that is awesome.

I’m very familiar with the UnityNuGet project; I’m its owner and maintainer since almost the very beginning.

That’s why I asked about NuGet support, because once it’s available, UnityNuGet project will be dead and will only be useful for older versions of Unity.

11 Likes

so the long domain reload and recompile loading bars won’t be gone?..

We’re working towards that outcome, but at the moment we don’t want to promise that we’ll have completed all the changes there in time for 6.8.

For Unity 6.8 all we are saying you should expect is “performance parity” - i.e. it will not be slower than Mono to iterate on your code with CoreCLR - but it may be that we don’t get to the big performance wins until 6.9+.

12 Likes

I get it, but I think you should all be prepared for a big group of people whining about “is that it?!”.
On the other hand, let’s not forget how DX12 performance parity with DX11 went (or still ongoing, idk cause I abandoned the idea totally and decided to stick with DX11)

2 Likes

Exactly why we’re trying to set expectations early :slight_smile:

6 Likes

I think some specific performance charts going around with poor interpretation might undermine this effort.

3 Likes

When we can provide data that better represents a real-world project - hopefully pulled from a real-world project - I’ll share.

8 Likes

When the Entities package becomes integrated in the editor, would we still be able to see its code?

Can you jump straight to C#15 support ? Union type please!

2 Likes

The existing functionality will be split between an internal module and a package. The package will be more-or-less as accessible as it is today.

Which set of types and functions go where isn’t final, but in general we’re only looking to move what’s strictly necessary into the internal module (very basic types and their support functions).

7 Likes

how exactly will the whole thing work after the integration? ive seen how dots works but never used it, will the editor ui change? will we need to do anything differently or write diff code?