From embedding Mono to Godot as a library and the future

[neikeq]

I'm writing this as a GIP as I could not think of a better way to discuss this with everyone. Sorry for not following the GIP template, I don't think it applies well in this case.

Godot supports C# as a scripting language by embedding the Mono runtime. Godot acts as the entry point for the application and takes care of initializing the Mono runtime and loading the required assemblies for execution. This proposal describes an alternative approach. The idea is for the entry point to be the C# application itself, which then would load Godot as a shared library (via DllImport or NativeLibrary). This proposal doesn't pursue the goal of making Godot more usable as a library (which could be great in any case), but only to make it possible to compile Godot as a shared library with an exported entry point for C# to call once at startup.

Motivation

The main motivation for this change is to reduce the workload needed on Godot's side to support C# on multiple platforms, fix bugs and stay up-to-date with newer .NET versions. By freeing ourselves from that we can focus on more important areas.

Taking only export/publish tooling into account, with this approach the .NET Sdk would already take care for us of Ahead Of Time (AOT) compilation and assembly trimming (of which the latter we don't yet support but would like to). AOT is something we already struggle with and assembly code trimming is a feature we would benefit from almost for free (we will still need to make the Godot C# API and game projects play well with code trimming).

Completely removes the need for us to do the work for building the Mono runtime (godot-mono-builds) for each target platform and for compiling Godot with it (part of build system code in the mono module, build-containers and godot-build-scripts). The .NET Sdk already provides the compiled runtimes.

Other benefits:

• Smaller Godot export templates (maybe even none at all?):
  • No longer need to include the Mono runtime and BCL for all target platforms. They are included in the .NET Sdk and their optional workloads.
  • No longer need to include the Godot engine itself as it would be provided as a native shared library via a NuGet package.
• Many existing issues might become obsolete. Issues related to our weird embedding use case where we're likely doing a few things wrong. Issues related to exporting, like native libraries from thirdparty NuGet packages not being included in exported games because Godot doesn't know about them when exporting a game.
• Better IDE support by default, less features need to be implemented in Godot IDE extensions. Projects would be runnable by default as they would be executable rather than library C# projects. A Godot extension would only need to add the more fancy features like Play in Editor.
• Benefit from platform-specific APIs in C# (from Xamarin.Android/iOS, etc).
• A less alien experience compared to the rest of the .NET ecosystem. At the very least at the build system level:
  • If you know how to enable AOT, trimming and similar features on C# projects, you know how to do it with Godot too as it's the same.
  • You don't need the Godot editor to export your games. Well, you do, but you can simply run dotnet publish and it takes care of everything for you. The plan is to make a MSBuild task that runs the Godot export command to export other Godot assets/PCK (exporting from the editor export dialog would still work too, that doesn't change).
• No more data folder on desktop platforms. .NET can publish self-contained single-file executables for Linux, Windows and macOS. Native libraries are not bundled by default though, so we would have libgodot.so/dll next to the executable. This is not worse than what we have now with the data folder next to the executable. Alternatively we can publish with the property -p:IncludeNativeLibrariesForSelfExtract=true to bundle native libraries, resulting now in a true single-file executable. Keep in mind native libraries bundled in the executable are extracted to a temp folder when running the app.

Downsides

• It's likely games published for the desktop will use the CoreCLR runtime (unless the .NET Sdk provides a way to swap runtimes). This could result in desktop games being bigger. I'm not sure about it though. For example, the Mono runtime plus mscorlib, System and System.Core assemblies amount to around 13.1MB without trimming (Linux x64). The following is from an attempt to publish a net5.0 hello world app:

  62.6MB Trim disabled
  21.3MB TrimMode=copyused
  12.6MB TrimMode=link

  TrimMode=copyused is the default trim mode and the safest. It only removes unused assemblies. TrimMode=link removes unused members too so it gives the best results but can cause issues with reflection and dynamic code generation. UPDATE: .NET 6 makes link safe to use, plus we may even replace reflection with source generators which makes scripts link safe as well. TrimMode=link gives us smaller results than we currently have in Godot 3.2, but what we have right now is not trimmed at all so it's not a good comparison. The best would be if the .NET Sdk allowed to choose between Mono and CoreCLR when publishing a desktop app, leaving the choice to the app developer (EDIT: This might already be possible in .NET 5 but it's not straightforward).

• Godot provides two ways to export Android games: with a prebuilt apk, or building a custom gradle/java Android project which is fully customizable. If someone is using the latter and after some time they decide to start using C#, then that custom gradle/java Android project needs to be rewritten in C#/Xamarin.Android. Perhaps I'm overestimating the number of developers using this custom Android project or the amount of work needed to move from it, but it would be ideal if a change in scripting language didn't require such work.

What work needs to be done

Some of the work involved to make this happen:

• Make Godot compilable as a shared library. This library needs at the very least export an entry point that can be called by C#.
• Support CoreCLR. I don't know if the .NET Sdk will allow swaping runtimes. If it's not possible to choose Mono on the desktop, we would need to support CoreCLR in addition to Mono. Godot relies on a lot of Mono embedding APIs. Supporting CoreCLR would require finding alternatives and/or moving many of those parts to C#. For C# to C++ calls we would use P/Invoke instead of Mono internal calls. P/Invoke doesn't allow to pass managed objects (we can pass gchandles though if needed). This may force us to rethink a few internals. UPDATE: We will be moving most interfacing code to C#. We will eventually use function pointers (C# 9 feature) instead of P/Invoke. Godot will not use any embedding APIs so it will work with all runtimes: Mono, CoreCLR and the experimental Native/CoreRT. NOTE: I think supporting CoreCLR would be needed any way if we want to support UWP. AFAIK Mono doesn't support that? But don't quote me on that! Never mind, Mono can run on UWP as commented below.
• For C# project we need to override the export process to work with MSBuild/dotnet publish.
• Distribute NuGet packages for the Godot C# API and the Godot native libraries.

When would this work begin

As soon as it's approved if that happens. As for the Godot version milestone, it depends whether Godot 4.0 is released before or after a .NET 6 release candidate. Preferably we want to use .NET 6, as .NET 5 doesn't support mobile. But if that isn't possible we have 3 options:

1. Implement this proposal with .NET 5 in Godot 4.0, with mobile support for C# delayed to Godot 4.1.
2. None of the above. Stay as we are for Godot 4.0, embedding Mono with the classic Mono BCL instead of .NET 5/6 support.
3. Release Godot 4.0 without C# support (either skip 4.0+C# or delay its release). I honestly prefer this over option 2 as I don't want to introduce a new major version that's known to still be going to cause trouble and needs to be supported for some time (we already have 3.2.x which has many pending fixes). And it doesn't feel right to then introduce a minor version that breaks both backward and forward compatibility... We've been doing this with C# in 3.x under the alpha/beta state excuse, but I wanted to stop that with 4.0.

UPDATE: The final decision is that Godot 4.0 will stay as is and this proposal will be implemented in Godot 4.1.

We're approaching the right time for a change like this. The work involved in switching to .NET 6 just to get back to our current state would likely be the same work if not more than the implementation of this proposal involves. That's without adding support for more platforms and features, which currently takes a lot of time and this proposal aims to simplify considerably.

So what do you think? Good? Yabai? Please let me know your thoughts.

[NHodgesVFX]

This looks amazing super excited for coreclr. Like I mentioned in chat I think it would be a good idea to make use of system.numurics wherever possible for the speed benefit. Maybe we can also make use of spans and the hardware accelerated math(in .net 6, we might get this for free if we use the relevant methods already). Although this could be added later if this part of the code doesnt need to be reworked for this proposal.

For the last part I believe Microsoft is targeting September for the release candidate. I don't think Godot would be released before then but as a fallback I vote for 1 as it doesn't leave c# users with no c# and it should be relatively easy to bump to .net 6 when its stable.

[Xartorx]

Looks awesome, ways better than current system. About Android - there's JNI, but using it comes with its can of worms.

Make Godot compilable as a shared library. This library needs at the very least export an entry point that can be called by C#

Could this be also good for other languages, ex. Rust or D? Because currently using GDNative is cumbersome, and using Godot as library would be easier than setting up GDNative and messing with gdns and gdnlib files.

[Calinou]

Could this be also good for other languages, ex. Rust or D? Because currently using GDNative is cumbersome, and using Godot as library would be easier than setting up GDNative and messing with gdns and gdnlib files.

GDNative is being rewritten for 4.0. It should be more convenient already: https://github.com/godotengine/godot/pull/44989

[Xrayez]

I'm writing this as a GIP as I could not think of a better way to discuss this with everyone. Sorry for not following the GIP template, I don't think it applies well in this case.

We must move to GitHub Discussions for this kind of workflow, see my meta proposal at #2069.

Once this is done, this proposal can be converted into a discussion without hassle. 🙂

[migueldeicaza]

This proposal has a bunch of different elements to it, and I think it should be broken up.

1. Consuming Godot as a shared library
2. Build changes for different form factors
3. Adding an option for using coreclr

Some observations:

On a Shared Library

This to me, it's probably the most interesting part of this proposal. There are several advantages of exposing Godot as a shared library, in addition to the points stated above, it can be used to easily embed the engine into existing applications that may have been written in other languages. For example, it could be used to augment an existing mobile application, or argument that's the publication with some content that was produced inside Godot.

Providing the engine as a shared library would enable scenarios we are game content can be as easily added to an application in the same way that webpages added to applications.

It is fun to me that this is being discussed now, many years ago I reached out to Juan inquiring precisely about this capability. At the time we wanted to allow developers to a 3-D content to their applications across multiple platforms (We were trying to provide across the platform 3-D engine that users could use). At the time this was not possible, so we end up picking up another open-source engine, it worked great, and many developers were able to create xplat solutions this way. The engine that we chose at the time is no match for the capabilities of Godot, and sadly no longer being maintained, so I am personally interested in getting a replacement for users.

Today there is a big gap in our industry for a cross-platform 3-D solution. I believe that this would solve problems for our large segment of developers.

On VM work

• The API for .NET 6 is breaking compared to the mobile profile in .NET
• New core APIs like span and numerics will be available on both runtimes (mono and coreclr)
• Mono can be used in UWP
• Easiest way to use coreclr would be to clone the embedding API of mono for coreclr (we did a proof of concept once), this ensures you still work on wasm, mobile and consoles which only work in mono
• if you are concerned about perf then you should try using the LVN backend for Mono

I would choose option (2) at least for a while, as there will be changes in the embedding APIs in this run times in the future so you might want to wait until those are sorted out. Additionally, the word that you need to swap run times and much of the work that is happening in .net 6 is still under development and will take a few more months before we even know what the shape of it is. I am personally a fan of limiting the amount of moving pieces, 4.0 it's a major change already.

[aaronfranke]

I don't like option 3 because it would make upgrading to 4.0 not an option for many people and would probably cause community outrage. Option 1 is not really ideal either. I think the best choice is option 2.

As Miguel says, there are still changes that need to be sorted out, and it doesn't make sense to me to switch to .NET 5/6/etc until those are sorted out (or otherwise we might have to "switch to it twice"). Also, people are going to have a hard time converting their projects from 3.2 to 4.0 anyway, so having 4.0 use Mono can be a blessing in disguise, and then C# users can just do additional work upgrading their projects to 4.1/4.2/etc.

It's OK if compatibility breaks with C# in a minor release in 4.x, we don't claim that the C# API is stable yet, and we have already broken C# compatibility in patch releases several times in 3.0.x and 3.2.x, so that would still be an improvement :)

[fab918]

For the shared library idea, I think mostly everyone agrees.

For the .net version:

As:

• Godot 4.0 should not arrive before the end of the year (They told in the last Q&A the alpha for godot 4 should come in April at best)
• .NET 6 preview is already out, and the release in planned to November
• .NET 6 is the replacement for .net core/.net framework
• .NET 6 is an LTS version

I think the best move is to focus on .NET 6 instead of investing time on a technology that is officially “dead”, need to invest in the future. Plus, the chance are very high that .Net 6 will be out before the Godot 4.0 release, and even in the worst case, I think the c# community will prefer to wait 1-2 months more to get .NET 6, it's a better investment for the future (or if 4.0 is ready in advance, wait novembre to release it, and benefit of the time to try to decrease issues)

For CoreCLR runtime, it's supposed to replace at the end mono runtime, it seems a good to invest on it, plus the size difference is low (event if being able to choice is always a plus). @neikeq , However .NET 6 not supposed supported both runtime out of the box (or I missed something)?

[autofool]

If this is implemented in future, I'm talking about Godot as library. Will it open possibility for adding c++ scripts more easily? Like without GDNative?

[edit] Ever since I started scripting in Godot whether it be GDScript or C#, I've noticed that Godot provides features to do everything by code that can be done in GUI editor. As I see, Godot is already very well developed to move it as library. Once that is done I can see how we can embed Godot like how LibGDX can be implemented as a small part of large application.

[migueldeicaza]

Hello,

Mono is the VM that supports Android, iOS, consoles and WebAssembly, and also part of the .net 6 platform. Switching to CoreCLR as the VM means none of those platforms will be supported by Godot.

[Delpire]

@migueldeicaza - What exactly does that mean? I'm still not very clear on what .NET 6 is supporting. It seems like more and more of the Mono runtime is going into the "core" .NET. .NET 5 only has support for Windows, MacOS, and Linux, but it looks like .NET 6 is adding support for Android, iOS, Apple's silicon, and Windows Arm64.

My understanding was that in addition to the netx.x targets (i.e. net5.0, net6.0), there will be a net6.0-android and net6.0-ios target. Part of the vision of MAUI was that you could have a single application that targeted multiple OS's (except Linux 😅). In Godot you have to export specific targets, would targeting those TFM's not be enough in .NET 6?

The only thing I see as missing is console and WASM support, thought I think WASM support must exist in .NET Core and .NET 5/6 since we have client side Blazor. (I believe its like .NET Core assembles being interpreted by a Mono WASM runtime or something like that).

Whether it be Mono or CoreCLR, I think the biggest gap in Godot's C# support (at least for me), is being able to use all the .NET tooling I use on a daily basis anyway. Being able to run my game from Visual Studio, debug without having a third party extension, use Visual Studio's profilers, or tools like PerfView. Maybe things would be less bad if Mono profiling for Godot wasn't broken on Windows, and maybe the problem is Godot not existing as a shared library, I'm not entirely sure, but I think whatever direction Godot goes in, y'all should think about those use cases. I already feel really efficient using C# with Godot, but if using Visual Studio and Godot at the same time was as seamless as working on a Blazor application, or a .NET 5 console app, it would be a big win.

[NHodgesVFX]

Hello,

Mono is the VM that supports Android, iOS, consoles and WebAssembly, and also part of the .net 6 platform. Switching to CoreCLR as the VM means none of those platforms will be supported by Godot.

This is incorrect. .Net6 will support those platforms by using mono in some form. Basically as @Delpire said. So with .net6 it will be possible to use both CoreCLR and mono. On consoles its will run just fine look at unity which uses c#.

[neikeq]

Reiterating what the previous replies have said, .NET 6 will have 2 runtimes: CoreCLR and Mono. Mono is the runtime that powers .NET 6 on mobile and wasm. The plan is for Godot to support CoreCLR in addition to Mono, not as a replacement.

[aaronfranke]

Long-term, does Microsoft have plans to make CoreCLR run on mobile and WebAssembly? Having different runtimes for different platforms doesn't seem like a good long-term solution (for either Microsoft or Godot).

If so, Godot could just wait, and later switch to CoreCLR and use it everywhere, when it's ready to be used everywhere.

[Delpire]

@aaronfranke - After some more reading, my understanding is that (as of 2019) Microsoft wants to keep Mono and CoreCLR as separate runtimes, with Mono focused on iOS and Android, and CoreCLR focused on desktop. They want to make the two of them drop in replacements for one another that you can control with a build switch. I think if this is what they envision for .NET, Godot should adopt it, and it should be possible to tell Godot which target to build. We already have separate exports for Windows, MacOS, Linux, Android, etc., they should just be able to change the target from net6.0 to net6.0-iOS or net6.0-android.

Its possible there will be APIs that still require either Mono or CoreCLR and not work on the other, if swapping between targeting net6.0 and net6.0-iOS is as easy as a build switch, then Godot users can just use conditional compilation for those iOS specific calls.

[neikeq]

Having different runtimes for different platforms doesn't seem like a good long-term solution (for either Microsoft or Godot).

For Godot, other than the initial effort to support the new runtime, it should not be an issue in the long-term. The idea is to move more code from C++ to C# and avoid dealing with each runtime API as much as possible. If we can do that, then most code will be shared for all runtimes. At some point we may also want to support CoreRT.

[neikeq]

@GeorgeS2019 We won't be using the embedding APIs anymore as we'll be moving the code that relies on them to C#. The Godot editor will still use embedding, but it will only use the CoreCLR host API to start the runtime, and load our helper assembly. I had a look at the Mono NETCore App runtime packages and it seems to export the CoreCLR host API, so the same code may even work for both runtimes.

[nobuyukinyuu]

If these changes make it easier to profile code written in c# I'm all for it. It seems extremely non-trivial to profile code with the current mono build in a way that's as easily accessible as either the Godot profiler or the VS one...

[aaronfranke]

@GeorgeS2019 Please be patient. Regardless of your urges and many posts, these things will take time.

[realvictorprm]

As much as I like the love for C# here I would like to add that it would be very good if the implementation doesn't limit the support to one specific language running on the CLR but works for all languages which can run on the CLR. My language of choice would be F# which doesn't work that well with Unity as it could work therefor I have high hopes for this here :)

[realvictorprm]

Side note, I don't ask for specific F# support with own api etc, just asking to do things such that the used laguage is not limited to be C# (which the other language can compensate via interop to a C# API)

[neikeq]

As much as I like the love for C# here I would like to add that it would be very good if the implementation doesn't limit the support to one specific language running on the CLR but works for all languages which can run on the CLR. My language of choice would be F# which doesn't work that well with Unity as it could work therefor I have high hopes for this here :)

I do want to make the implementation language agnostics to allow for third-parties to add other CLR languages with the same features as we have for C# and without workarounds like having an empty .cs file with the same name as placeholder. However first we need to focus on good C# support.

[voronoipotato]

So long as it is a library we F# folks can write a shim, we are somewhat used to higher friction. Right now as a near term solution I'm trialing leveraging GDNative with F# to avoid these kinds of workarounds and being constrained to just using mono. So this topic is pretty exciting to me.

[realvictorprm]

So I would like to way in here and help out getting this stuff done sooner :) however I'm not sure how much effort it requires and whether it makes sense for me as my time unfortunately is quite limited because now that I work full time I have way less time :/ let me know whether you're happy to have additional resources :)

[reduz]

Just a follow up from my side. With @vnen we are rewriting GDNative entirely and converting it into a low level extension API (no longer a script API). May also probably rename it to GDExtension avoid confusion.

With the new API you will be able to do pretty much everything you do with modules, such as registering objects to class DB, and the entire Godot API is a single C function pointer away. We still have some work to do, but I think it may be interesting to evaluate if .NET makes more sense to use this, as it has the potential to simplify the code a lot to make it hot-pluggable.

The general idea is to leave the script API to dynamically typed languages such as GDScript or VisualScript, while compiled languages work via the extension system. This way, the GDnative C++ and other bindings such as Rust, Nim, etc. will no longer work like scripts, and instead like modules. This means you register a class and thats it, it appears in the engine ready to use as a node, resource, etc. with documentation and everything.

The main rationale behind this is that .NET is compiled, for which it makes more sense it acts like a module/extension than a scripting language.

[minim271]

The general idea is to leave the script API to dynamically typed languages such as GDScript or VisualScript, while compiled languages work via the extension system. This way, the GDnative C++ and other bindings such as Rust, Nim, etc. will no longer work like scripts, and instead like modules. This means you register a class and thats it, it appears in the engine ready to use as a node, resource, etc. with documentation and everything.

This may also be helpful for cross language interoperability, "Register a class" can make it more convenient to use it in GDScript. And that reducing the "black box" in cross language interop witch can help developers better understand what happened. For example, I like to use C# to write core logic as a library, and use GDScript to build other parts(GUI, simple logic, etc), I love the dynamics of GDScript, the above changes can make the whole process more controllable.

Considering that one of the meanings of supporting C# is to attract developers from unity, maybe it's helpful to encapsulate a script API based on this？

[neikeq]

While the new ClassDB extensibility API sounds great, it's not really encompassed in this proposal so let's not discuss it here. If any one is wondering though, I do want to support that in C#.

[Shadowblitz16]

This means you register a class and thats it, it appears in the engine ready to use as a node, resource, etc. with documentation and everything.

@reduz are you saying we will finally be able to make true custom node types? if so I'm in.

[aaronfranke]

@Shadowblitz16 Yes, that's the idea. There is also discussion of whether we should make that the only option, so every script created in GDNative (and maybe every script created in C#) shows up and behaves just like an actual built-in engine type.

[realvictorprm]

Would you folks be open for contributions which as soon as this arrives adds basic F# support in the editor?

[Calinou]

Would you folks be open for contributions which as soon as this arrives adds basic F# support in the editor?

The Godot script editor doesn't have full C# support in the first place, so F# support isn't a goal right now. Adding full C# support to the Godot script editor would require turning it into a LSP client, which is a lot of work.

[aaronfranke]

@Calinou I'm pretty sure @realvictorprm was just talking about things like allowing creating F# scripts from the create script dialog and allowing Godot to compile and run them.

[realvictorprm]

Exactly @aaronfranke, this would be the first step.

Besides, as fancy as it sounds to have full F# scripting support in the engine, as bad is the idea to actually implement it in my opinion. I think the engine should not focus on having a geat editor as we already have great editors out there (VSCode, IntelliJ, Atom etc.). More importantly the engine's build system should be in such a state, that it's possible to easily integrate build scripts for additional languages + easy ways to seamlessly integrate the workflow of developing in an external editor or IDE of your choice. Therefor I would focus my effort on the build system side of the engine (e.g. adding the dialog to add F# files) and in that process also trying to ensure that it's working with multiple languages (if it's a feature which should be supported language independ).

The only thing which I would support/try additionally, as it's not too difficult (famous last words 😄), is simple syntax highlighting for F# scripts, but that's it. For anything more you would need support for the LSP, which, as already outlined by @Calinou, is a huge effort.

[chismar]

So, can anyone provide some update on how the process is going on? What's done, what's to be done? I know that it can't exactly be finished before .net 6 releases, but at least to understand how it progresses would be nice.

[neikeq]

The decision was to postpone this proposal (including .NET 6 support) until Godot 4.1. Not much work has been done yet other than starting to move code to C#. All the work in progress will go into the dotnet6 branch.

As for what's to be done, the only steps that are clear so far are:

• Move code to C#.
  • Marshaling and internal calls. Mostly done with godotengine/godot#48409, pending some code.
  • Rest of the code. Several parts from csharp_script.cpp and gd_mono*.cpp files.
  • At this point I may start playing more with source generators. For example, I want to replace reflection + marshaling type checks for invoking methods and accessing properties on scripts from the engine.
• Replace embedding Mono with CoreCLR hosting/embedding and introduce .NET 6 support. Only for the editor, as export templates will be used as libraries instead of embedding as this proposal explains. This doesn't mean we stop using Mono as explained in previous comments.
  • Export templates will stop working for now.
  • Assembly reloading will stop working for now (AppDomains no longer supported).
• Re-add assembly reloading with AssemblyLoadContext.

Everything else will be decided as things progress.

[viksl]

I'm just curios but was there or could there be a contact with miscrosoft about a possible grant with this project in mind since they are pushing the latest and neweswt net6? Well, I'm not sure if this question belongs here so I apologize if it's off-topic.

[reduz]

Will clarify a few things: @neikeq The idea in Godot 4.0 onwards is that compiled languages can extend the engine, and extensions can be loaded and unloaded at any time, when obtained from asset library.

This opens the door at users writing extensions for other users in any language they like (C++, Rust, Nim) then you get shared objects that you load into the engine and immediately extend the engine API and provide native nodes, not scripts.

Making Mono work by controlling the Godot entry point fundamentally goes against this vision, as it will make the language not play along the others nicely. If most users preferred C# and this was the unique language available, it would make sense but currently it sits around 20-30% of the userbase, the rest strongly prefers to use GDScript, C++ and a smaller niche prefers other languages such as Rust or Nim.

In other words, the idea is that, if some user makes a fanstastic terrain plugin in C#, and wants to make it available to others using GDScript or C++ for their game, the plugin should install normally and allow other users to continue using Godot as always. Right now this is not possible because using C#/Mono requires a separate engine build, so I would put most of my effort to make sure that this is made possible via the new extension system, rather than focusing on the approach suggested in this proposal.

I am not against the fundamemtal idea of the proposal, as it can definitely be of use to some and we could implement it, but it would strongly exclude others if it this was the default way of using it.

[neikeq]

The idea in Godot 4.0 onwards is that compiled languages can extend the engine, and extensions can be loaded and unloaded at any time, when obtained from asset library.

The new extensions API is very great for many reasons and I plan to add support for it in C# (albeit I still wish it allowed namespaces). However, those benefits are mainly for native language bindings that used GDNative. The C# bindings already supports all that.

In other words, the idea is that, if some user makes a fantastic terrain plugin in C#, and wants to make it available to others using GDScript or C++ for their game, the plugin should install normally and allow other users to continue using Godot as always.

When it comes to the Godot editor this GIP doesn't change much as the editor will still use embedding as it does now. Godot would be used as a shared library only in exported games. Regarding those, when I wrote this I kept in mind that nothing should break for projects using a different language that at some point decide to start using C#. Right now the only caveat is Android (and perhaps iOS), which I mention in the downsides:

• Godot provides two ways to export Android games: with a prebuilt apk, or building a custom gradle/java Android project which is fully customizable. If someone is using the latter and after some time they decide to start using C#, then that custom gradle/java Android project needs to be rewritten in C#/Xamarin.Android. Perhaps I'm overestimating the number of developers using this custom Android project or the amount of work needed to move from it, but it would be ideal if a change in scripting language didn't require such work.

But who knows, maybe with some extra effort I may be able to keep the prebuilt apk and the java gradle project working with C#.

Right now this is not possible because using C#/Mono requires a separate engine build, so I would put most of my effort to make sure that this is made possible via the new extension system, rather than focusing on the approach suggested in this proposal.

Although not formalized as a GIP, there's a plan to include C# support without needing a separate Godot editor build. This GIP doesn't prevent that. It even moves us a bit in that direction by not bundling a .NET runtime and its framework libraries with the Godot editor.

[reduz]

@neikeq My point is mostly that you will have users wanting to use an add-on made with C#, and they don't care about what's going on with C# or launching Godot as a library. If this helps somehow while making an actual project in C#, it can eventually be added, but the priority should be to make it work like the rest of the scripting languages. Additionally, if we support this in C#, it is possible other languages will want to go this route, making the system incompatible between them.

The main advantage of the extension system is that it pretty much allows you to use Mono in stock Godot and stock export templates, which is not possible today, It is not a replacement of the script API, but a lower level way to interact with the engine.

Regarding namespaces, I see no problem implementing some support for this, but from the extension API it sounds like it will most likely just be no more than adding a namespace string while registering the extension class.

[andreakarasho]

just FYI: using NativeAOT you can static link libraries in the csproj:

<ItemGroup>
 <NativeLibrary Include="SDL2.lib" />
</ItemGroup>

[GeorgeS2019]

just FYI: 3D engine as an embedding library for the project reunion of .NET6

WinForm for Visual Basic and c# remains one of the biggest developer segments for Window.

Now finally an embedding 3D engine library is available as part of the Project reunion of .NET6. This opens out 3D game/visualization for WinForm/WPF/UWP developers with modern Windows technologies and new features, plus the best of existing Desktop (aka Win32) features

3D for project reunion will address the 3D visualization enterprise/corporation needs when transitioning to .NET6 this Nov 2021.

[tapir]

There hasn't been much updates in this proposal, is it still the case that this will come out with 4.1 and Godot as a .NET 6.0 library?

[daerogami]

To add to @tapir's follow up question. @reduz mentioned a GDNative rewrite would provide possible support as a shared library. What issues/PRs is that effort captured by?

[GeorgeS2019]

@tapir

This PR introduces many changes before the upgrade to .NET 6 (from the current .NET 5). After this PR is merged I'll rebase the dotnet6 branch and then push a few other important changes before the dotnet6 branch can be merged into master.

@daerogami => sounds like thing will soon speed up.

[NHodgesVFX]

I'm curious has anything been said about web support of c# with .net 6 since it seems its now possible to compile directly to wasm. If godot can use that tool chain as well it would be much faster. I tried it out with a blazor app that does image processing and got a 16x speed improvement.

I guess this is for the future though considering godot 4 doesn't support web export at the moment anyway.

[GeorgeS2019]

@NHodgesVFX

Tentatively, I imagine we need a JavaScript -Godot Bridge

This will eventually involve Blazor JavaScript interop

Sharing here so we can gather discussion.

However, it is best to create a separate proposal once there is sufficient interest.

I have discussed this briefly with FinePointCGI#2036 at Godot Discord. Feel free to feedback him for more ideas what to do next.

[GeorgeS2019]

@andreakarasho

Godot 4 .NET6 C#: Initial NativeAOT support

[GeorgeS2019]

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

[GeorgeS2019]

A few of us are attempting to make Godot4 .NET6 (dotnet6 branch) running and we are getting good support from the Godot Team!

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

[GeorgeS2019]

Below is a feedback from a few of us who recently attempting to understand how the on-going Godot4 dotnet branch works. This is a draft and covers only a small part of the proposed alternative approach. We hope more users will come forwards and take what we have done to different topics for discussion to speed up the process (community coordinated) needed to support the Godot team to complete the process of migration from embedding mono to .NET6 runtime.

The preliminary findings with feedback from the Godot team and other effort

• Godot dotnet6 branch notes
• Dotnet interop playground: attempt to understand how NativeAOT works in Godot4 dotnet6 context

Godot supports C# as a scripting language by embedding the Mono runtime.

• Godot acts as the entry point for the application and
• Godot takes care of initializing the Mono runtime and loading the required assemblies for execution.

This proposal describes an alternative approach.

• The alternative involves c# application as the entry point and no longer the Godot
• The C# application would load Godot as a shared library (via DllImport or NativeLibrary).
• The C# application takes care of initializing the Godot shared library ('__Internal') through the exported entry point for c# to call once at startup
• The Godot shared library is now "embedded" as part of GodotSharp.dll and will be provided as NuGet.
• dotnet6 commit : Make GodotSharp API a NuGet package

Motivation

The main motivation for this change is to reduce the workload needed on Godot's side to support C# on multiple platforms, fix bugs and stay up-to-date with newer .NET versions. By freeing ourselves from that we can focus on more important areas.

With this alternative approach, the Godot team no longer takes care on maintaining Mono issues associated with supporting multiple platforms: building the Mono runtime (godot-mono-builds) for each target platform and for compiling Godot with it (part of build system code in the mono module, build-containers and godot-build-scripts).

The alternative approach means the .NET Sdk provides the compiled runtimes for multiple platforms.

(Some of the listed) other benefits:

• Smaller Godot export templates (maybe even none at all?)
• Better IDE support by default, less features need to be implemented in Godot IDE extensions. Projects would be runnable by default as they would be executable rather than library C# projects. A Godot extension would only need to add the more fancy features like Play in Editor.
• Benefit from platform-specific APIs in C# (from Xamarin.Android/iOS, etc).

How Godot .NET community could START contribute ?

Bring the following points to discussion?

• Follow the godot team's C# Godot 4.0 Roadmap
• Follow and make coordinated user initiatives: e.g. Godot dotnet6 branch notes on what PoCs have been done and shared.
• Currently the available dotnet6 branch commits focus on desktop. Support and coordinated initiatives are needed to other platforms (e.g Android/iOS etc) and PERHAPS the feasibility for supporting MAUI or Blazor.
• Extend one user initiative to understand how the dotnet6 commit : NativeAOT works for desktop to mobile or perhaps web
• Share ideas for better IDE experience for development and better Godot dotnet6 specific testing framework made possible by the alternative .NET6 approach

[GeorgeS2019]

For many waiting for the next batch of dotnet6 commits scheduled for March/April 2022, here is a preliminary list