Add support for embedding natively compiled .NET 7.0 assemblies

[nonunknown]

Recently I've watched this video its super interesting the fact that you can build into native code, because this will open a HUGE door for godot development, because for example:

Suppose you're doing a gdscript based game, in case you use an addon or library specific from C# this means the end user (player) will need to have mono installed on his machine, but compiling to native code this isnt necessary anymore!

please comment your toughts!

[musicm122]

This looks really interesting.

Introduction:

A couple more resources I've found.

• Native AOT Hello World
• Native AOT Deployment

I don't know the inner workings of Godot 4+ but, there are some limitations with regards to Native AOT. I'm not sure if any of these would be potential roadblocks.

Limitations:

Native AOT applications come with a few fundamental limitations and compatibility issues. The key limitations include:

• No dynamic loading (for example, Assembly.LoadFile)
• No runtime code generation (for example, System.Reflection.Emit)
• No C++/CLI
• No built-in COM (only applies to Windows)
• Requires trimming, which has limitations
• Implies compilation into a single file, which has known incompatibilities
• Apps include required runtime libraries (just like self-contained apps, increasing their size, as compared to framework-dependent apps)
• The publish process will analyze the entire project and its dependencies and produce warnings whenever the limitations could potentially be hit by the published application at runtime.

The first release of native AOT in .NET 7 has additional limitations. These include:

• Should be targeted for console type applications (not ASP.NET Core).
• Not all the runtime libraries are fully annotated to be native AOT compatible (that is, some warnings in the runtime libraries are not actionable by end developers).
• Limited diagnostic support (debugging and profiling).
• Build native libraries

Source

[nonunknown]

thanks for the info, although there's a lot of limitation, I think .Net7 support will take a long time to be implemented in godot, so I think until there, most of the limitations should be gone, but ofc, having this would be a HUGE thing!!!

[Hanprogramer]

No dynamic loading is the biggest roadblock here. Until it's possible there's no way Native AOT can be implemented in godot I think. (Or it might be possible with source gen... not sure)

[RiversJohn]

Ought to be possible to write a sourcegen lib that provides the integration statically at compile time,
if the team is willing to take this chore on is another matter obviously as it isn't exactly trivial to get the first implementation done even if extending it wouldn't be hard.

.Net 7 solves a lot of the limitations and .Net 8 even more so, some of the limitations are also really not issues that would impede any of the real use cases with Godot.

It would still involve several weeks to up to a month or few to get it all in shiny state.

[ayremon]

Any news on this road?

[brokolja]

This could possibly reevaluated now that AOT for exporting in general works (got it working with net 9 and godot 4.4) and it would be huge when we could package native-aot addons somehow. For example when we could create addons using c#, packaging it as native aot, non c# users would be able to just install godot without c# but use the addon and its signals/nodes etc usign gdscript.

[swissdude15]

How exactly did you proceed? I tried it, but the export build crashes with:

ERROR: .NET: Failed to get GodotPlugins initialization function pointer at: (modules/mono/mono_gd/gd_mono.cpp:484) ERROR: Parameter "godot_plugins_initialize" is null. at: initialize (modules/mono/mono_gd/gd_mono.cpp:653)