[Internal test] 4.7-dotnet1

Caution

This is a pre-release and may contain bugs. Be sure to make frequent backups, or use a version control system such as Git, to preserve your projects in case of corruption or data loss.

Minimum requirements

• .NET SDK 9.0.200 or newer.

Workflow changes

The main difference from the old integration is that C# scripts are gone, the C# language is no longer a script-based language. Instead, the C# language is implemented as a GDExtension language binding.

As a result, C# classes are now registered within the engine as GDExtension classes. This simplifies the process and allows us to fix some longstanding issues as we're no longer limited by the requirements of Godot's ScriptLanguage APIs.

This changes the workflow slightly from the old integration, but it still remains mostly the same. You can see some videos comparing the old and new workflow in this Google Drive folder.

Warning

In this pre-release, reloading C# assemblies is still not implemented. After creating C# classes, you have to build the C# project and reopen the editor, so the new class is registered and shows up in the dialogs. We're working on fixing this for the upcoming releases.

Bindings changes

The new bindings are mostly the same as the old bindings. Most of the bindings are generated from the Core Godot API which hasn't changed. However, there are some changes worth mentioning:

• Some APIs and types were renamed (e.g. Array -> GodotArray).
• Packed arrays are now implemented as dedicated types instead of using C# arrays.
• Virtual methods are now protected instead of public.
• Some attributes were renamed to match the GDExtension APIs to register members.
• Internal APIs that were exposed (i.e. the entire Godot.NativeInterop namespace) are no longer public.
• Singletons are now instance classes instead of static. They can be accessed using the static Singleton property.

Upgrading existing projects

The new Godot .NET integration includes an upgrade tool that will automate the process of upgrading existing Godot projects. The upgrade is performed automatically when opening the project in the editor, so make sure to make a backup before opening any project you want to preserve in case something goes wrong.

Warning

While in most cases we expect the tool to make all the changes needed to make your project compatible with the new integration, there may be cases that require manual changes. Some changes may require specific knowledge of your project and how it's intended to work that can't be automated.

Setting up NuGet packages

We haven't published the NuGet packages ye, so you need to create a local NuGet source feed and copy the packages there. You can follow the development instructions.

In short, you create a directory somewhere and create a NuGet source feed with the following command:

dotnet nuget add source <my_local_source> --name MyLocalNugetSource

Replace <my_local_source> with the path to the directory you created.

Then, copy the .nupkg files included in the godot-dotnet-4.7.dotnet1.zip compressed archive to that directory.

Report feedback

You can open new issues about this pre-release on the godot-dotnet repository. Thank you for helping us test the new Godot .NET integration!

[C#] Fix thread deadlock when using a worker thread to load a script with a generic base class

• Custom build to test godotengine#99798

[.NET] Add a preload hook to load .NET assemblies from the APK

• Custom build to test godotengine#105262

C#: Fallback to CoreCLR/MonoVM hosting APIs when hostfxr/NativeAOT fails (2)

• Custom build to test godotengine#88803 from commit f78d359

C#: Fallback to CoreCLR/MonoVM hosting APIs when hostfxr/NativeAOT fails

• Custom build to test godotengine#88803