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: godotengine/godot#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 :)

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

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 godotengine/godot#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 like Play 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 #4773 being implemented first.

[GeorgeS2019]

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