CoreCLR Discussion Thread - Unity 6.7 Alpha

[Jdance-Media]

Hello everyone, I figured I'd make a more formal GitHub thread for discussing Unturned in terms of upgrading its runtime to CoreCLR when Unity 6.8 comes out.

As many of you have seen, Unity released a "Path to CoreCLR, 2026" discussion post with some details on experimenting with CoreCLR in Unity 6.7a2. There are some specific things that broke due to .NET modernization, but it is about three individual issues with the U3-SDK code that can be easily resolved.

This week, I went ahead and upgraded the U3-SDK Unity project to 6.7a2 and set the scripting to be CoreCLR. Upon fixing some slight issues with libraries and Unity phasing out instance IDs, it works like a charm. The U3-SDK runs exactly like you'd expect on the Mono runtime with CoreCLR.

So, I wanted to mention what I've figured out so far:

• Modern plugins made after 2021.3+ (targeting .NET Standard 2.1) should remain relatively compatible. Dependencies will need to be upgraded to either .NET Standard 2.1 or .NET 10 versions from NuGet.
• .NET 10 works with plugins and modules. The Unity Editor is not compatible with any APIs outside of .NET Standard 2.1, but the CoreCLR runtime used is the one from .NET 10, so external libraries can be .NET 10.
• Modern debuggers will now work with the game on development builds. As BlazingFlame pointed out to me, Debugger.Launch() will allow you to use the Visual Studio debugger. This is incredibly useful for looking at local values and setting up breakpoints.
• Performance and gameplay is similar, but there are some things to note for later:
  • This transition and implementation of CoreCLR isn't finished.
  • The newest .NET versions historically have better performance metrics than Mono.
  • The garbage collector is reportedly not upgraded yet (Unity is still on Bohem GC but will be switching to CoreCLR GC).
• Unity staff said in April that a NuGet package manager is not planned. You will have to manually copy over libraries from NuGet.

I don't necessarily think that the path to switching to Unity 6.8 should be a PR submitted by someone, but rather SDG voluntarily upgrading it when it becomes viable. With that being said, it seems that the upgrade should be smooth in terms of the vanilla game and the main quirks will probably come out of the nature of it being an engine upgrade.

Debugger prompt being triggered in the CoreCLR build:

If some people have some thoughts, suggestions for use cases, and other information on the .NET modernization, please feel free to add to this post.

[DanielWillett]

Would definitely be a nice upgrade in the plugin development department, I think the biggest pro being that we can use the latest Entity Framework library which is an SQL wrapper (ORM). Most modern .NET 10 libraries can already be loaded with some work if they have a netstandard2.X target, which most do like System.Text.Json or any of the Microsoft.Extensions libraries. Also most of the missing language features can be brought back with Polyfills such as PolySharp.

On the other hand, this will break a ton of plugins. Any plugin built for .NET Framework, which is most of them out there, will not load without a few minor changes and a rebuild. Also, @Trojaner will probably have some thoughts on this re. the ImperialPlugins loader.

As much as it pains me to say I don't think its worth upgrading any time soon unless the performance gain is actually very noticeable.

Another alternative could be keeping two branches for U3DS: Mono and CoreCLR which could allow server hosts to use older plugins but those that want to upgrade or have a performance boost can use the CoreCLR build.

[Jdance-Media]

Yeah, you are right. Most of the plugins created in the last few years have been targeting .NET Standard 2.1, but anything older than that that we are still reliant on will need to be rebuilt. I'd like to think that the performance gain once Unity finalizes all of this will be significant, but we'll have to see.

I think it might be plausible to have two different branches for U3DS to at least start with. I do look back to #4131 where it was brought up that breaking plugin is sometimes better in the name of progress. I think we can agree on at least testing out a CoreCLR version of the dedicated server in some kind of testing phase or beta branch. Afterall, all engine upgrades have to sit on a beta branch for a while anyways.

[Trojaner]

This would break the ImperialPlugins native loader and hence all plugins on ImperialPlugins.com. Given the fundamental architectural differences to mono, it's not clear if it could ever be ported to .NET CoreCLR at all. Even if it could be ported, it's not clear if all plugins on ImperialPlugins would remain compatible with it (even under mono some plugins are not compatible and break, hence they were written in a way that they work with the native loader).

A simple claim like ".NET 10 works with plugins and modules" requires rigorous and sophisticated testing on various platforms, including various Linux distributions with more than a few older major releases for each of them, all Windows versions up to Windows Server 2012 as well as recent macOS releases and of course this would need to be done with a large and representative amount of plugins (of which a big chunk is not available freely and where some are even completely private).

Honestly I don't see .NET Framework being that relevant when it comes to limitations plugin developers face. RocketMod's architectural decisions have always had a much bigger impact there.

[DanielWillett]

I think Jdance just meant that plugins built for net10.0 are able to be loaded, not that existing plugins work, but yeah i def agree that you can do a lot with just the .NET Standard 2.1 compatibility layer. Spans, most C# 10-14 features (except static interface members), EFCore 5, etc all can be made to work with a bit of headache.

[Jdance-Media]

You read ".NET 10 works with plugins and modules." somewhat wrong -- I was referring to plugins and modules targeting .NET 10. The bullet point above that talks about .NET Standard 2.1 plugins being relatively compatible. As you said yourself, it is a "native loader" and isn't the same thing as a typical plugin library.

Using modern .NET opens us up to the use of modern libraries and APIs that we could manage without but are just nice to have in general. I'm hoping that there is another solution for creating a plugin loader, even if it differs greatly from the original ImperialPlugins native loader.

[kulkaGM]

I don't see a reason to halt the game progression because someone's business based on shipping plugins made for indie game will have downtime or will get completely obsolete after nearly idk? A decade?
Mine stuff will get eFed too but nobody would care if I said anything. So lets just do it.

Separate branch would be good for testing ahead (public repo will be enough aswell), announce the date the full change will (IF) happen officially and lets goo.
No package manager? Meh. That's a small price for me.

[Jdance-Media]

What price? The Unity Editor never had the NuGet package manager anyways. I just mentioned it because it seems relevant, given that you'd expect them to add it with the latest .NET support. 😭

[kulkaGM]

What I meant is that it is not not big of a deal. They aren't trying things for no reason, chances are they will make package manager so they have more things to offer and if not, there won't be any drawback afaik except the unfortunate plugins and servers, which shouldn't gatekeep the progress of this SDK anyway.