Kompilieren mit .NET

Anforderungen

  • .NET SDK 8.0+

    Sie können dotnet --info verwenden, um zu überprüfen, welche .NET SDK-Versionen installiert sind.

Aktivieren Sie das .NET-Modul

Bemerkung

Die C#-Unterstützung für Godot hat in der Vergangenheit die Mono-Runtime anstelle der .NET-Runtime verwendet, und intern werden viele Dinge immer noch als Mono anstelle von Dotnet benannt oder auf andere Weise als Mono bezeichnet.

Standardmäßig ist das .NET-Modul bei der Erstellung deaktiviert. Um es zu aktivieren, fügen Sie die Option module_mono_enabled=yes zur SCons-Kommandozeile hinzu, während Sie ansonsten den Anweisungen zum Erstellen der gewünschten Godot-Binärdateien folgen.

Generieren Sie den Glue

Parts of the sources of the managed libraries are generated from the ClassDB. These source files must be generated before building the managed libraries. They can be generated by any .NET-enabled Godot editor binary by running it with the parameters --headless --generate-mono-glue followed by the path to an output directory. This path must be modules/mono/glue in the Godot directory:

<godot_binary> --headless --generate-mono-glue modules/mono/glue

Mit diesem Befehl wird Godot angewiesen, die C#-Bindings für die Godot-API unter modules/mono/glue/GodotSharp/GodotSharp/Generated und die C#-Bindings für die Editor-Tools unter modules/mono/glue/GodotSharp/GodotSharpEditor/Generated zu generieren. Sobald diese Dateien generiert sind, können Sie die Godot-Managed Libraries für alle gewünschten Targets erstellen, ohne diesen Prozess wiederholen zu müssen.

<godot_binary> bezieht sich auf die Editor-Binärdatei, die Sie mit aktiviertem .NET-Modul kompiliert haben. Sein genauer Name hängt von Ihrem System und Ihrer Konfiguration ab, sollte aber die Form bin/godot.<Plattform>.editor.<arch>.mono haben, z.B. bin/godot.linuxbsd.editor.x86_64.mono oder bin/godot.windows.editor.x86_32.mono.exe. Achten Sie besonders auf das Suffix .mono! Wenn Sie Godot zuvor ohne .NET-Unterstützung kompiliert haben, haben Sie möglicherweise ähnlich benannte Binärdateien ohne dieses Suffix. Diese Binärdateien können nicht verwendet werden, um den .NET-Glue zu erzeugen.

Bemerkung

Die Glue-Quellen müssen jedes Mal neu generiert werden, wenn sich die in der ClassDB registrierte API ändert. Das wäre zum Beispiel, wenn eine neue Methode in der Skripting-API registriert wird oder sich einer der Parameter einer solchen Methode ändert. Godot gibt beim Start einen Fehler aus, wenn die API zwischen ClassDB und den Glue-Sourcen nicht übereinstimmt.

Bauen der Managed Libraries

Once you have generated the .NET glue, you can build the managed libraries with the build_assemblies.py script:

./modules/mono/build_scripts/build_assemblies.py --godot-output-dir=./bin

Wenn alles gut gegangen ist, sollte das GodotSharp-Verzeichnis, das die Managed Libraries enthält, im bin-Verzeichnis erstellt worden sein.

Bemerkung

Standardmäßig teilen sich alle Entwicklungs-Builds eine Versionsnummer, was zu Problemen beim Zwischenspeichern der NuGet-Pakete führen kann. Um dieses Problem zu lösen, verwenden Sie entweder GODOT_VERSION_STATUS, um jedem Build eine eindeutige Version zu geben oder löschen Sie GodotNuGetFallbackFolder nach jedem Build, um den Paket-Cache zu löschen.

Im Gegensatz zu "klassischen" Godot-Builds kann bei der Erstellung mit aktiviertem .NET-Modul (und je nach Target-Plattform) ein Datenverzeichnis sowohl für den Editor als auch für exportierte Projekte erstellt werden. Dieses Verzeichnis ist wichtig für das ordnungsgemäße Funktionieren und muss zusammen mit Godot veröffentlichen werden. Weitere Einzelheiten zu diesem Verzeichnis finden Sie in Datenverzeichnis.

Build-Plattform

Geben Sie das Argument --godot-platform=<platform> an, um zu bestimmen, für welche Plattform die Bibliotheken gebaut werden sollen. Lassen Sie dieses Argument weg, um für das aktuelle System zu bauen.

Dies regelt derzeit nur die Aufnahme der Unterstützung für Visual Studio als externen Editor, ansonsten sind die Bibliotheken identisch.

NuGet-Pakete

Die API-Assemblies, Source-Generatoren und das benutzerdefinierte MSBuild-Projekt-SDK werden als NuGet-Pakete veröffentlicht. Für den Benutzer ist dies alles transparent, aber es kann die Dinge während der Entwicklung kompliziert machen.

Um Godot mit einer Entwicklungsversion dieser Pakete zu verwenden, muss eine lokale NuGet-Quelle erstellt werden, in der MSBuild sie finden kann.

Wählen Sie zunächst einen Speicherort für die lokale NuGet-Quelle. Wenn Sie keine Präferenz haben, erstellen Sie ein leeres Verzeichnis an einem der folgenden empfohlenen Orte:

  • Unter Windows: C:\Benutzer\<Benutzername>\MyLocalNugetSource

  • Unter Linux, *BSD, usw., ~/MyLocalNugetSource

Dieser Pfad wird später als <my_local_source> bezeichnet.

Nachdem Sie ein Verzeichnis ausgewählt haben, führen Sie diesen .NET CLI-Befehl aus, um NuGet so zu konfigurieren, dass Ihre lokale Quelle verwendet wird:

dotnet nuget add source <my_local_source> --name MyLocalNugetSource

Wenn Sie das Skript build_assemblies.py ausführen, übergeben Sie <mein_lokaler_quellcode> an die Option --push-nupkgs-local:

./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source>

Diese Option stellt sicher, dass die Pakete zur angegebenen lokalen NuGet-Quelle hinzugefügt werden und dass konfliktbehaftete Versionen des Pakets aus dem NuGet-Cache entfernt werden. Es wird empfohlen, diese Option beim Erstellen von C#-Lösungen während der Entwicklung immer zu verwenden, um Fehler zu vermeiden.

Building without depending on deprecated features (NO_DEPRECATED)

When building Godot without deprecated classes and functions, i.e. the deprecated=no argument for scons, the managed libraries must also be built without dependencies to deprecated code. This is done by passing the --no-deprecated argument:

./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source> --no-deprecated

Unterstützung von Double-Precision (REAL_T_IS_DOUBLE)

Wenn Godot mit Unterstützung für Double-Precision gebaut wird, d.h. mit dem Argument precision=double für scons, müssen die Managed Libraries angepasst werden, indem das Argument --precision=double übergeben wird:

./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source> --precision=double

Beispiele

Beispiel (Windows)

# Build editor binary
scons platform=windows target=editor module_mono_enabled=yes
# Build export templates
scons platform=windows target=template_debug module_mono_enabled=yes
scons platform=windows target=template_release module_mono_enabled=yes

# Generate glue sources
bin/godot.windows.editor.x86_64.mono --headless --generate-mono-glue modules/mono/glue
# Build .NET assemblies
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source> --godot-platform=windows

Beispiel (Linux, *BSD)

# Build editor binary
scons platform=linuxbsd target=editor module_mono_enabled=yes
# Build export templates
scons platform=linuxbsd target=template_debug module_mono_enabled=yes
scons platform=linuxbsd target=template_release module_mono_enabled=yes

# Generate glue sources
bin/godot.linuxbsd.editor.x86_64.mono --headless --generate-mono-glue modules/mono/glue
# Generate binaries
./modules/mono/build_scripts/build_assemblies.py --godot-output-dir ./bin --push-nupkgs-local <my_local_source> --godot-platform=linuxbsd

Datenverzeichnis

Das Datenverzeichnis ist eine Abhängigkeit für Godot-Binärdateien, die mit aktiviertem .NET-Modul erstellt wurden. Es enthält wichtige Dateien für das korrekte Funktionieren von Godot. Es muss zusammen mit der ausführbaren Godot-Datei veröffentlichen werden.

Editor

Der Name des Datenverzeichnisses für den Godot-Editor wird immer GodotSharp lauten. Dieses Verzeichnis enthält ein Api-Unterverzeichnis mit den Godot-API-Assemblies und ein Tools-Unterverzeichnis mit den vom Editor benötigten Tools, wie den GodotTools-Assemblies und deren Abhängigkeiten.

Unter macOS kann, wenn der Godot-Editor als Bundle veröffentlichen wird, das GodotSharp-Verzeichnis in das <bundle_name>.app/Contents/Resources/-Verzeichnis innerhalb des Bundles gelegt werden.

Exportvorlagen

Das Datenverzeichnis für exportierte Projekte wird vom Editor während des Exports erzeugt. Es heißt data_<APPNAME>_<ARCH>, wobei <APPNAME> der Anwendungsname ist, wie er in der Projekteinstellung application/config/name angegeben ist, und <ARCH> die aktuelle Architektur des Exports ist.

Im Falle von Exporten mit mehreren Architekturen werden mehrere solcher Datenverzeichnisse erstellt.

Kommandozeilenoptionen

Im Folgenden finden Sie eine Liste der Kommandozeilenoptionen, die bei der Erstellung mit dem .NET-Modul verfügbar sind:

  • module_mono_enabled=yes | no

    • Bauen von Godot mit aktiviertem .NET-Modul.