Add .NET Core support

[Maratonec]

Describe the project you are working on:
Support .NET core and also Mono for different types of games

Describe the problem or limitation you are having in your project:
In issue 2 years old you said that .NET core is too young, but now after to years you should implement it, because of better performance and platform independence.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
Microsoft is now saying that .NET core is the main implementation of C# so it should be great to implement it. It is also easier for users, because Visual Studio now comes with .NET core.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
User will choose type of project and there will be .NET core that will support its compilers and libraries and also writing code in Visual Studio.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
No, I am sure many users will be very happy if you implement it so it will be used very much and sadly for you this implementation of .NET core will not be few lines of code for you.

Is there a reason why this should be core and not an add-on in the asset library?:
I thing it would be impossible to implement this in assets library because of it’s size.

Thanks,
Maratonec

[Calinou]

See also #339.

[Maratonec]

See also #339.

Thanks but that issue is for NetStandart that is also in mono version. I want to add Net core because of better performance, more libraries and that it comes with visual studio

[nobuyukinyuu]

.net Core is supposedly being unified with the mainline framework when it reaches version 5. I think we should wait until this happens to support Core, since by that time all new projects will likely be targeting it. ETA for version 5 is the end of the year.

[neikeq]

Mono will support .NET 5 (the re-branded .NET Core), so we should be able to migrate to that at some point. Whether it will be possible to do that for Godot 4.0 or not I cannot say yet.
We're not going to switch to CoreCLR though. We will keep using the Mono runtime.

[FeatherAntennae]

On the Microsoft / .NET 5 side of thing, the idea is that .NET 5 will basically unify .NET Framework 4.8, Mono 5.0, and .NET Core 3.0.

Mono has been bringing code over from .NET Core for a while and both sides are kinda completing that work with .NET 5, bringing the two compiler technologies together. The AOT compiler from Mono / Xamarin will be added and enabling the mobile technologies to run on top of the JIT is coming with .NET 5.

The Common Language Runtime implementation will be unified across Mono and .NET Core and the library system on top will be honed to different scenarios. There will be a set of libraries for mobile, a set of libraries for microservices, a set of libraries for desktop development and so on.

They don't see Mono going away though, as there's still big applications that depend on Mono and may never port to use .NET 5.0.

As for the mono side of things, I have a hard time finding anything on what's coming and what the plans are for the future.

[AlseinX]

Correcting some misunderstandings of .NET Implementations:

1. The obsolescence of .NET Framework happens right after the GA release of .NET Core 3.0, not .NET 5. This is because the last release of .NET Framework (4.8) shares the same api level (.NET Standard 2.0) with .NET Core 2.x, and will never support .NET Standard 2.1 that later .NET Core and Mono supports.
2. .NET Framework is obsoleted, not unified to .NET 5. And .NET 5 is a later rebranded version of .NET Core 3.1 and irrelative to .NET Framework 4.8 in fact. What .NET 5 directly "inherits" from .NET Framework is nothing but the version number.
3. Mono is a part of .NET 5 for its AOT compiler, which is widely used in iOS projects (Xamarin and Unity), and its CLR, which runs slower but has less file size than .NET Core, but it will not have extra API collection or TFM. It will be only the alternative runtimes to Core CLR.

Conclusion:

1. The API support of .NET Framework is an obsoleted solution, even for now, months before .NET 5's GA release.
2. It have to support .NET Standard 2.1 (and .NET 5 in the future), regardless of what runtime is used.

[NHodgesVFX]

It would be cool to be able to use CoreCLR with Godot as it seems RyuJit is always faster then Mono
https://github.com/nxrighthere/BurstBenchmarks

As far as AOT with CoreCLR https://github.com/dotnet/runtimelab/tree/feature/NativeAOT is making progress although its still experimental.

With .Net 5 and Godot 4 release, maybe it will be possible to allow users to choose whether they want to use CoreCLR or Mono. At least for desktop platforms CoreCLR seems to be a better way to go.

.Net 5 also makes improvements to native interop
https://devblogs.microsoft.com/dotnet/improvements-in-native-code-interop-in-net-5-0/

[GeorgeS2019]

@neikeq I just tested the Using System.Threading.Tasks throws error with .NET 5.0 as build tool. with the Godot 3.3rc7 and the latest .NET5.0.5 or .NET 5.0: SDK 5.0.202

It seems .NET5 has much to go before it is able to cover the current mono implementation in Godot.

Ideally, we need more of this test, using .NET5 dotnet CLI to compile godot mono projects to feedback to the CoreCLR team on what could be missing in .NET5/6.

Mono future will be Mono VM for [1] mobile, [2]console & [3] WebAssembly and NOT desktop under .NET6

Currently we are revealing Mono Desktop features through the latest .NET 5 (e.g. 5.0.5)

The CoreCLR team will put focus on Mono VM for the 3 platforms (listed above) but not Desktop.

==> Do you think we will have a longer path to climb eventually to port Godot Mono API to Godot CoreCLR API for desktop As the CoreCLR team may not deal with the Mono aspect relevant to Godot path to CoreCLR (for Desktop) ?

I hope I express this concern sufficiently clear or I could have miss understand something else.

[GeorgeS2019]

Examples of .NET6 (or .NET Core for mobile solutions)

I suggest we consolidate the discussion to here

Please also see the recent plan

[ryancheung]

I just want to mention the issue Developers using the Mono embedding API can upgrade to modern .NET in dotnet runtime repo. Unfortunately the issue is not in .NET 6 milestone.

[neikeq]

I just want to mention the issue Developers using the Mono embedding API can upgrade to modern .NET in dotnet runtime repo. Unfortunately the issue is not in .NET 6 milestone.

The plan is to move away from embedding Mono and to make Godot usable with Mono, CoreCLR and the experimental Native/CoreRT without depending on any embedding API being ready for .NET Core: #2333.

[ryancheung]

I just want to mention the issue Developers using the Mono embedding API can upgrade to modern .NET in dotnet runtime repo. Unfortunately the issue is not in .NET 6 milestone.

The plan is to move away from embedding Mono and to make Godot usable with Mono, CoreCLR and the experimental Native/CoreRT without depending on any embedding API being ready for .NET Core: #2333.

Yeah, I saw your proposal and that is awesome!

[GeorgeS2019]

Finally, we no longer deals with .NET Core but beyond .NET core, which is .NET6
C#: Upgrade to .NET 6 (5.0 -> 6.0)

AND

First attempt to merge .dotnet6 branch to master has started.

We are now ready to discuss:

The plan is to move away from embedding Mono and to make Godot usable with

• Mono,
• CoreCLR and
• the experimental Native/CoreRT

without depending on any embedding API being ready for .NET Core

[GeorgeS2019]

I think we can close this proposal

A few of us are attempting to make Godot4 .NET6 (dotnet6 branch) running.

https://gist.github.com/lewiji/2b86f47dcb142a10e104504a343c38ff

[knightofiam]

@GeorgeS2019 Reading over your gist, I think this should stay open until fully working and integrated - which probably won’t happen until Godot 4 is released and runs through some patch cycles. I definitely appreciate all of your hard work as I use C# / .NET 5 in my Godot 3 project and am looking forward to upgrading when stable!

[SupinePandora43]

Finally, we no longer deals with .NET Core but beyond .NET core, which is .NET6
C#: Upgrade to .NET 6 (5.0 -> 6.0)

AND

First attempt to merge .dotnet6 branch to master has started.

We are now ready to discuss:

The plan is to move away from embedding Mono and to make Godot usable with

• Mono,
• CoreCLR and
• the experimental Native/CoreRT

without depending on any embedding API being ready for .NET Core

NativeAOT will be officially available in net7.0

Mono

Pros

• Easy embedding api
• Mobile support

Cons

• Possible lower performance in comparison with CoreCLR

CoreCLR

Pros

• Fast
• Main desktop runtime

Cons

• No mobile support

NativeAOT

Pros

• No need to use runtime directly.
• Fast startup

Cons

• No JIT
• Larger size of a binary
• Longer compile times
• No mobile support
• Separate builds for every os-architecture combination

[NHodgesVFX]

I think depending on perspective no jit is a pro, you do lose some dynamic stuff but you gain increased performance and the ability to support platforms where jit is not allowed. Additionally NativeAOT should result in smaller binarys not larger ones since theirs no IL.

[SupinePandora43]

I think depending on perspective no jit is a pro, you do lose some dynamic stuff but you gain increased performance and the ability to support platforms where jit is not allowed. Additionally NativeAOT should result in smaller binarys not larger ones since theirs no IL.

JIT can optimise code. Without JIT code may be slower. But it can be fixed by static pgo.

NativeAOT binary can be bigger than default stripped mono on net6.0-android when supporting multiple architectures. (fixed on android by per-arch apk files)

NativeAOT binary size will differ from a lot of factors. It's not worth talking about.

[lewiji]

NativeAOT Godot exports are working for me on dotnet6 branch. I haven't tested extensively, and only exporting as a debug release for a Linux target, so far, but I could verify publishing a game worked as did running it, with a basic hello world script attached.

The binary was bigger than the equivalent mono export, but since I can't test out release builds yet (currently they strip out the interop functions needed to communicate with godot without mono) it's not a very meaningful comparison.

[aaronfranke]

This has been implemented in godotengine/godot#64089.

Godot now supports .NET 6, which is the evolution of .NET Core.