MelonLoader

MelonLoader

242 Downloads

.NET 9 Mono

ds5678 opened this issue ยท 1 comments

commented

Context

We discussed this in Discord, and there are a few main problems to using .NET 9 with Unity.

Reference: https://unity.com/blog/engine-platform/porting-unity-to-coreclr

Ensure objects don't move.

Unity stores MonoObject* pointers to access managed objects. This can be to invoke methods on them (such as Awake), deserialize fields, or anything else that the Mono API allows.

Compacting can be disabled with native patching or a custom build.

https://github.com/dotnet/runtime/blob/0cba4a126edefdc0584e21fb7e180e44aa2e7b88/src/coreclr/gc/gc.cpp#L45144

Ensure objects aren't collected unless there are no references in native code.

Unity uses Boehm to search the entire stack. We'll probably have to do the same. Keeping objects alive forever is likely not an option.

Handle any AppDomain issues.

This might not be a runtime issue. The primary problem with app domains was Unity using them to reload assemblies in the editor.

Mono C APIs

This was briefly mentioned above, but Mono exposes a bunch of C APIs that Unity uses. CoreCLR does not expose these APIs. We either have to recreate them or use the .NET 9 Mono code, which is slower, but should work out of the box. .NET 9 Mono is used for Android and WASM.

https://github.com/dotnet/runtime/tree/main/src/mono

commented

As nice as it may seem to create a wrapper for the Mono API, it would take a LOT of effort and time to pull off. The mono API is HUGE and would probably require a lot of people to work on it.

Next to this, you'll also have to consider MethodImpl InternalCalls, which will always throw on CoreCLR. You'd have to edit the assemblies to implement another communication method.