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.

[ghostbutter-games]

Not sure if this is the right place to post this, but I'd like to add: If there is any way to add the new dotnet watch feature that enables Hot Code Reload, allowing for changing the program while it is running – that would be amazing for Godot development and make me and probably everyone using C# with Godot very happy.

Immediate feedback is a killer feature, really great for creative work and something I'm missing when using C# over GDScript, so yeah, would be great to at least see if this could be possible.

[ghostbutter-games]

Sorry for the double post, but I think this warrants a separate post:

Could someone clarify what the current plan of action is regarding the future of C# and Godot 4.X? I read through the entire issue and am still confused, seems to me like there has not been a decision made yet?

• Will .NET 6 be implemented in the same fashion as the Mono Runtime was implemented until now?
• Will this use the new GDExtension API, or will it continue to be a separate Editor binary like it was/is with Godot Mono?
• Is the plan to implement this for 4.0 or 4.1? (In my opinion waiting for 4.1 would be really disappointing for the substantial amount of devs currently using C#, ~20% is a lot and I reckon many of those would like to switch to 4.X as soon as possible)

Would love to keep on using Godot with C# in the future and really just trying to understand where we're headed. Maybe @neikeq can clarify?

[GeorgeS2019]

@kopkako

I only speak as someone outside the Godot team who believes in growing the Godot .NET community.

I will not feedback on the questions you raised directly but using this opportunity to lobby for MORE Godot .NET enthusiasts to step forwards like yourself to voice your opinions.

As a Godot .NET user, I could not yet now understand with sufficient overview the challenges of adopting the GDExtension API and what it means in terms of how long further we need to wait for BEFORE we have a working and up-to-date with the master branch environment like GDScript 2.0 but for Godot4 for .NET developers.

I see the following options and which directions we will go depending a lot on more feedback from the Godot .NET community to step forwards to share their views.

A few weeks back (~15th March 2022), a few of us get our feet wet in learning more about the status of the Godot4 dotnet6 branch because we have similar concerns as @kopkako

Option 1: In an ideal case, Godot4 support both the vision of GDExtension API and the existing .NET6 path side by side in ways that are synergistic: both paths co-exist in a win-win way.

First, we can start discussing the feasibility of option 1 NOW without waiting.

Although the existing dotnet6 branch is not up-to-date as the master branch, it has provided the possibilities to start thinking/discussing, testing (Linux and Windows), and even possibly planning WHAT COULD BE the benefits of staying and keeping the .NET6 path, in co-existent with the GDExtension. This requires more Godot .NET users to step forwards. For example, how likely to implement dotnet watch? If so, how long do we need to wait to get there?

Option 2: eventually there will be ONLY GDExtension for c# developer.

At some point, after the merging of dotnet6 branch, it will transition FULLY into the GDExtension API.

It is unclear how feasible is that and how easy to keep the benefits of having a c# application as the entry point which opens to the benefits (partly or fully) of the .NET6/NET7 ecosystem.

I encourage more .NET users to step forward to share your view!

[ghostbutter-games]

@kopkako

I only speak as someone outside the Godot team who believes in growing the Godot .NET community.

I will not feedback on the questions you raised directly but using this opportunity to lobby for MORE Godot .NET enthusiasts to step forwards like yourself to voice your opinions.

As a Godot .NET user, I could not yet now understand with sufficient overview the challenges of adopting the GDExtension API and what it means in terms of how long further we need to wait for BEFORE we have a working and up-to-date with the master branch environment like GDScript 2.0 but for Godot4 for .NET developers.

I see the following options and which directions we will go depending a lot on more feedback from the Godot .NET community to step forwards to share their views.

A few weeks back (~15th March 2022), a few of us get our feet wet in learning more about the status of the Godot4 dotnet6 branch because we have similar concerns as @kopkako

Option 1: In an ideal case, Godot4 support both the vision of GDExtension API and the existing .NET6 path side by side in ways that are synergistic: both paths co-exist in a win-win way.

First, we can start discussing the feasibility of option 1 NOW without waiting.

Although the existing dotnet6 branch is not up-to-date as the master branch, it has provided the possibilities to start thinking/discussing, testing (Linux and Windows), and even possibly planning WHAT COULD BE the benefits of staying and keeping the .NET6 path, in co-existent with the GDExtension. This requires more Godot .NET users to step forwards. For example, how likely to implement dotnet watch? If so, how long do we need to wait to get there?

Option 2: eventually there will be ONLY GDExtension for c# developer.

At some point, after the merging of dotnet6 branch, it will transition FULLY into the GDExtension API.

It is unclear how feasible is that and how easy to keep the benefits of having a c# application as the entry point which opens to the benefits (partly or fully) of the .NET6/NET7 ecosystem.

I encourage more .NET users to step forward to share your view!

Thanks for your reply!

I share many of those sentiments and would like to add: I believe C# was and still is the ideal candidate for a compiled, type-safe & fast language besides GDScript, for more advanced users. I would personally not want to build complex games with GDScript, coming from Unity – having C# as a first-class option is really important to me, so I would like to see it integrated as well as possible.

Of course, the point of contention is: Should C# be "better integrated" than, say, Rust or C++ via GDExtension. I do think so, because C# is very suitable for a very huge selection of game developers, more so than native languages. It is high level enough for rapid iterations & concise, readable code yet fast enough for very demanding simulations. The .NET runtime only keeps getting better and faster, so I would suggest that 95% of devs do not need more performance than what is possible with C# and Godot 4.X, going forward.

So, basically GDScript is the official, easy-to-use beginner-friendly integrated language, and C# the more advanced language for users who want to make more complex games that take several years to build.

Also, I personally think that (judging from that last survey Juan did), >20% devs using C# is actually a really large segment, given that the Godot Mono version is not marketed as the default, and having GDScript as the much more accessible first language.

I really wish for Godot to further embrace C# as a first-class language and keep it tightly integrated, as I think it fits absolutely perfectly and I would like to preferably work with this for the rest of my career as a game developer.

[neikeq]

• Will .NET 6 be implemented in the same fashion as the Mono Runtime was implemented until now?

It has diverged completely from how we were doing things when embedding Mono. However, unlike what's described in this proposal, Godot is still the entry point of the application, which uses the .NET hosting APIs. I still plan to make it possible for the C# application to be the entry point. That will happen in Godot 4.1 or later, depending on its benefits (it may actually be a requirement if some .NET tools don't work well with custom .NET host apps).

• Will this use the new GDExtension API, or will it continue to be a separate Editor binary like it was/is with Godot Mono?

Those two things are not related. There will only be one editor binary, which will include C# support (some dependencies may not be included by default, but the editor will download them transparently). No more Classic vs C# versions of Godot.

Regarding the GDExtension system, it's not clear yet whether C# will switch to it. My initial expectation was that GDExtension would introduce usability regressions compared to the scripting system, but the benefits would make it worth. However, later I found some serious issues that make it outright unsuitable for scripting (see godotengine/godot#57427, for example). Those issues may end up being fixed in time, but for now I'm playing safe and staying with the scripting system.

• Is the plan to implement this for 4.0 or 4.1? (In my opinion waiting for 4.1 would be really disappointing for the substantial amount of devs currently using C#, ~20% is a lot and I reckon many of those would like to switch to 4.X as soon as possible)

This proposal is outdated, but mostly everything here is confirmed for Godot 4.0, except for the following:

• C# app as the entry point. As explained above, this will happen in Godot 4.1 or later.
• Mobile support. No decision made yet, I'm waiting for the maui release.

[paulloz]

There will only be one editor binary, which will include C# support (some dependencies may not be included by default, but the editor will download them transparently). No more Classic vs C# versions of Godot.

This is IMHO a fantastic decision.

[Delpire]

@neikeq Will the scripting approach have an affect on debugging or performance monitoring compared to the GDExtension approach. My biggest pain points with Mono are that debugging requires special set up with either VSCode or Visual Studio (extensions, mono runtime, etc.), and performance monitoring with Mono seems to be broken on Windows. Another big pain is that inspecting variables while debugging sometimes doesn't work. My hope was that with .NET 6, these issues would just work natively with Visual Studio, likely simply through attaching to the process after running (I suppose having a C# app as the entry point in the future would make this even quicker).

[ghostbutter-games]

@neikeq Thanks so much for the writeup, I really appreciate it! ❤️ This makes me really happy and hopeful for the future of C# and Godot, I love that there will only be one editor going forward. This will also hopefully greatly unify the user base and benefit everyone.

Still trying to wrap my head around what it would mean for my dev workflow if the .NET app becomes the entry point instead of Godot. Would this have very heavy consequences for the way I would work with Godot, or is it more of a technical backend detail at the end of the day?

I am asking this because I am planning to build a rather involved Godot Mono tooling project, starting in 3.X and was hoping to eventually port that to 4.X – would that still be theoretically possible, or would everything break?

[ghost]

I'm a bit confused about something. If there will be only one binary release for 4.x and around 4.1 or so godot will have completed .NET 6 integration, does that mean I can use the engine's debugging features like I can with gdscript?

[GeorgeS2019]

@Calinou Could you elaborate on why it is an incompatibility break?

[Calinou]

@Calinou Could you elaborate on why it is an incompatibility break?

Switching from Mono to .NET Core will break compatibility by design, since the APIs exposed to users will change to some extent. There's nothing that can be done to prevent this. I don't know what will break exactly, just that some breakage is expected.

[chismar]

Ahoy, friends, long time no see. Can anyone do a little status update on how dotne6 integration into the Godot 4.0 going on? Any new ETAs?

[GeorgeS2019]

Source: C# Godot 4.0 Roadmap

Additional source: C# plans towards Godot 4.0

Incomplete list

C# Godot 4.0 Roadmap: 1

Committed: Assembly reloading

C# Godot 4.0 Roadmap: 2

Committed: C#: Implement IReadOnly*<> interfaces on Godot's Array<> and Dictionary<,> classes

C# Godot 4.0 Roadmap: 3

Committed: Source generator for signals as events

C# Godot 4.0 Roadmap: 4

Committed: C#: Represent Variant as its own type instead of System.Object

C# Godot 4.0 Roadmap: 5, 10

Committed WIP:

• Array<> and Dictionary<,> marshaling delegate
• Refactor Array & Dictionary interface implementations

• Array and Dictionary now store Variant instead of System.Object.
• Removed generic Array and Dictionary. They cause too much issues, heavily relying on reflection and very limited by the lack of a generic specialization.
• Removed support for non-Godot collections. Support for them also relied heavily on reflection for marshaling. Support for them will likely be re-introduced in the future, but it will have to rely on source generators instead of reflection.
• Reduced our use of reflection. The remaining usages will be moved to source generators soon. The only usage that I'm not sure yet how to replace is dynamic invocation of delegates.

C# Godot 4.0 Roadmap: 6, 9

Draft PR: {6}: Fix P/Invoke symbols stripped in optimized builds; {9}:Source generator for invoking constructors via func ptr instead of reflection

C# Godot 4.0 Roadmap: 7

Incremental source generators [Source: C# plans towards Godot 4.0]

Godot 4.0 will make extensive use of source generators to remove the need for reflection and runtime type checking when invoking C# code from the engine.

C# Godot 4.0 Roadmap: 8

Committed: c#: Source generator for registering classes

C# Godot 4.0 Roadmap: 15, 16

WIP PR: Add C# resource export could be relevant

[GeorgeS2019]

FYI: relevant to follow the latest feedback from @neikeq at Godot Contributor chat regarding merging the dotnet6 branch

Source: C# Godot 4.0 Roadmap Additional source: C# plans towards Godot 4.0

C# Godot 4.0 Roadmap: 19

GodotSharp NuGet packages [Source: C# plans towards Godot 4.0]

Currently, the Godot API assemblies are distributed with the Godot editor, which copies it to a game project for MSBuild to be able to find them.

Going into Godot 4.0 we will instead distribute the Godot API assemblies as NuGet packages. This removes the dependency from the Godot editor and allows MSBuild to build the C# project before previously having to open the project with the Godot editor.

Editor Unification [Source: C# plans towards Godot 4.0]

Previously, I mentioned there won’t be two separate versions of export templates (Standard vs Mono/C#). I want to extend this to the Godot editor as well. Up until now, we had two separate versions because the Mono/C# version increased the size a lot due to its dependencies. This is no longer the case, as we don’t bundle any .NET dependencies anymore.

• [ ] The .NET runtime must be loaded lazily, only when actually needed.
• [ ] Failing to load the .NET runtime should not abort the editor process. It should just behave the same as not being able to load the project assembly (continue with features disabled).
• [ ] It should be possible to specify a custom .NET Sdk location in the editor settings.
• [ ] GodotTools assemblies should be downloaded by the editor, instead of being downloaded with Godot. Albeit, it's only 1.2 MB (0.5 MB if we can replace the Newtonsoft.Json dependency with System.Text.Json).
• [ ] GodotPlugins, GodotSharp and GodotSharpEditor should be downloaded by the editor. GodotPlugins is only 10 kB. The API assemblies are NuGet packages, so they could be downloaded from the NuGet repository instead of our download site.

C# Godot 4.0 Roadmap: 20

[GeorgeS2019]

@Calinou

Do you think it is appropriate to change the milestone from 4.1 to 4.0?

[GeorgeS2019]

Motivation

Other benefits:

I now have a better idea that this is related to Editor Unification

• [ ] 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.

[azur-wolve]

Motivation

Other benefits:

I now have a better idea that this is related to Editor Unification

* [ ]  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.

Someone is trying to integrate (embedding) VS Code within Godot Editor: https://www.reddit.com/r/godot/comments/wl3u86/embedding_vscode_directly_into_the_godot_editor/

[azur-wolve]

Yes I know. But isn't it interesting for C#? I thought that integrate C# on the Script Workspace were in the roadmap, now that many Unity users are migrating to us.

[paulloz]

now that many Unity users are migrating to us

This really doesn't change anything. Anybody coming from Unity is already used to having an IDE for code on the one side and the engine on the other, since the engine (imho rightfully) doesn't provide an integrated one.

[RedMser]

@KiwwiPity Do note that this is a very hacky approach which is never intended to be an "officially endorsed" solution. I wouldn't point newcomers to the engine to this extension, since it breaks some core functionality (like debugging from within Godot, double-click to connect signals, shortcuts are captured by the IDE, can't view documentation from editor, etc.).

I'd rather see Godot's own code editor improved further as a long-term solution (such as with hover hints https://github.com/godotengine/godot/pull/63908 , better autocomplete search, splitting windows etc.).

[azur-wolve]

now that many Unity users are migrating to us

This really doesn't change anything. Anybody coming from Unity is already used to having an IDE for code on the one side and the engine on the other, since the engine (imho rightfully) doesn't provide an integrated one.

Didn't knew that Unity hasn't an IDE

[Shadowblitz16]

now that many Unity users are migrating to us

This really doesn't change anything. Anybody coming from Unity is already used to having an IDE for code on the one side and the engine on the other, since the engine (imho rightfully) doesn't provide an integrated one.

Didn't knew that Unity hasn't an IDE

it doesn't have a official built in editor ide but you can download one for free or buy one

[GeorgeS2019]

What could be NEXT after dotnet6 merged?

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 likePlay in Editor.

The proposal spoke about improving Visual Studio IDE experience. Here we are making debugging using Visual Studio (e.g. 2022) more reliable. Please bring WHAT YOU THINK should be improved in e.g. VS2022 experience to this discussion.

[daerogami]

That's really it.

I just want to be able to start the project from my own entry class so I can do other cool stuff like using the ecosystem around Microsoft.Extensions.Hosting.IHostBuilder. Is it the right tool for the job? Probably not, but if the IDE experience was that seamless, that would be wicked neat to call something like builder.AddGodotEngine() and have DI ready to go out-of-the-box.

I would be absolutely willing to help write those NuGet extension packages. Problem is I don't write much C++ these days, so the interop stuff and getting the godot libraries to build/package is something I would need to pair up with someone on.

[neikeq]

Regarding the C# application being the entry-point, it's still something I would like to see, but it's definitely not happening in 4.0 and likely not in 4.1 either, which will focus on mobile (although the mobile port may work that way).

Most of the other things mentioned here are already done or WIP, and they are coming in Godot 4.0. I'm going to close this proposal as it's old and covered a lot of things. Further discussion would be better tracked in separate threads.

Before it's inclusion in an official release, I plan to make a blog post detailing what's new for C# in Godot 4.0.

[GeorgeS2019]

they are coming in Godot 4.0

[azur-wolve]

@GeorgeS2019 @neikeq hi there what's going on with Godot 4 C# progress, there's some thread to keep track of the progress and so?

EDIT: it looks like are those if not outdated: https://github.com/orgs/godotengine/projects/30/views/1 https://docs.google.com/document/d/1f3NeaTBnn6KtVR7ZMIoKPKdabEBp8JO0W1WeAoPVoHc/edit#heading=h.u2ukrnbem3t5

[tvardero]

I don't think this issue should have been closed back then. As we haven't yet achieved Godot as a library.

Also comes to think:

• Silk.Net
  • Silk.Net.Math for generic vectors;
  • Silk.Net.Input for window inputs and mouse cursors;
  • Silk.Net.Windowing for windows management;
  • Silk.Net.OpenGL / Vulkan / DirectX, so we don't have to continue implementing own support. And instead focus more on the engine, that will glue all these together. As well as contributing what we have already achieved to Silk.Net.
• Microsoft.Extensions.Hosting (web devs know that as WebApplicationBuilder), which comes with:
  • MS.Ext.Logging
  • MS.Ext.Configuration
  • MS.Ext.DI
  • MS.Ext.Options

All that is Ms.Ext. - is half-abstraction, half-default implementation, you can use Autofac, NInject, Serilog, NLog and whatever you want on top of Ms.Ext.

P.S. Btw the feature i really lack in Godot is DI.

[GeorgeS2019]

@tvardero

Many of us move on to this c# discussion

You are right with Silk.Net

Godot4 team is working HARD on DirectX driver. It is working now 90 to 95%. This needs more people to test.

Once that is done, Godot4 with .NET6 has a good chance to address one of the major gaps in .NET 3D ecosystem.

The lack of a mature MIT license 3D engine, non Unity, to meet WinUI and Maui and Blazor Business requirements.

Please open new issues and draw attention through here and Godot Discords focusing on C#/.NET

FYI :: Godot4 includes NativeAOT, something MAUI team needs to support

[Calinou]

Using Godot as a C# library is likely dependent on https://github.com/godotengine/godot-proposals/issues/4773 being implemented first.

[GeorgeS2019]

@Calinou thanx for pointing out that it is 4.x