summaryrefslogtreecommitdiff
path: root/modules/mono/editor/Godot.NET.Sdk
AgeCommit message (Collapse)Author
2021-12-05Bump Godot.NET.Sdk and SourceGenerators versionsRaul Santos
Bump `Godot.NET.Sdk` to version 4.0.0-dev6. Bump `Godot.SourceGenerators` to version 4.0.0-dev3. Use floating version 4.0.*-* for package references in Sdk.
2021-12-05Fix Godot.SourceGenerators for generic classesRaul Santos
Fix invalid C# generated by source generators for generic classes and add generic classes to the Sample project for testing.
2021-07-23Add a simple C# .editorconfigAaron Franke
2021-03-13C#: Fix ScriptPathAttribute generator with none or nested namespacesIgnacio Etcheverry
The following two bugs were fixed: - For classes without namespace we were still generating `namespace {` without a namespace identifier, causing a syntax error. - For classes with nested namespaces we were generating only the innermost part of the namespace was being generated, e.g.: for `Foo.Bar` we were generating `namespace Bar {` instead of `namespace Foo.Bar {`. This wasn't causing any build error, but because of the wrong namespace Godot wasn't able to find the class associated with the script.
2021-03-06Add C# source generator for a new ScriptPath attributeIgnacio Etcheverry
This source generator adds a newly introduced attribute, `ScriptPath` to all classes that: - Are top-level classes (not inner/nested). - Have the `partial` modifier. - Inherit `Godot.Object`. - The class name matches the file name. A build error is thrown if the generator finds a class that meets these conditions but is not declared `partial`, unless the class is annotated with the `DisableGodotGenerators` attribute. We also generate an `AssemblyHasScripts` assembly attribute which Godot uses to get all the script classes in the assembly, eliminating the need for Godot to search them. We can also avoid searching in assemblies that don't have this attribute. This will be good for performance in the future once we support multiple assemblies with Godot script classes. This is an example of what the generated code looks like: ``` using Godot; namespace Foo { [ScriptPathAttribute("res://Player.cs")] // Multiple partial declarations are allowed [ScriptPathAttribute("res://Foo/Player.cs")] partial class Player {} } [assembly:AssemblyHasScripts(new System.Type[] { typeof(Foo.Player) })] ``` The new attributes replace script metadata which we were generating by determining the namespace of script classes with a very simple parser. This fixes several issues with the old approach related to parser errors and conditional compilation. It also makes the task part of the MSBuild project build, rather than a separate step executed by the Godot editor.
2020-10-23C#: Make editor create NuGet fallback folder for Godot packagesIgnacio Etcheverry
Main benefits: - Projects can be built offline. Previously you needed internet access the first time building to download the packages. - Changes to packages like Godot.NET.Sdk can be easily tested before publishing. This was already possible but required too many manual steps. - First time builds are a bit faster, as the Sdk package doesn't need to be downloaded. In practice, the package is very small so it makes little difference. Bumped Godot.NET.Sdk to 4.0.0-dev3 in order to enable the recent changes regarding '.mono/' -> '.godot/mono/'.
2020-10-09Mono: Fix typo in Godot.NET.Sdk.nuspecRémi Verschelde
Fixes #42666.
2020-09-23Rename the ".mono" folder to ".godot/mono"Aaron Franke
2020-09-18Fix typos with codespellRémi Verschelde
Using codespell 1.17.1. Method: ``` $ cat > ../godot-word-whitelist.txt << EOF ang curvelinear dof doubleclick fave findn leapyear lod merchantibility nd numer ois ony que seeked synching te uint unselect webp EOF $ codespell -w -q 3 -I ../godot-word-whitelist.txt --skip="./thirdparty,*.po" $ git diff // undo unwanted changes ```
2020-07-25C#: Switch games to MSBuild Sdks and .NET StandardIgnacio Etcheverry
Godot.NET.Sdk ------------- Godot uses its own custom MSBuild Sdk for game projects. This new Sdk adds its own functionality on top of 'Microsoft.NET.Sdk'. The new Sdk is resolved from the NuGet package. All the default boilerplate was moved from game projects to the Sdk. The default csproj for game project can now be as simple as: ``` <Project Sdk="Godot.NET.Sdk/4.0.0-dev2"> <PropertyGroup> <TargetFramework>netstandard2.1</TargetFramework> </PropertyGroup> </Project> ``` Source files are included by automatically so Godot no longer needs to keep the csproj in sync when creating new source files. Define constants ---------------- Godot defines a list of constants for conditional compilation. When exporting games, this list also included engine 'features' and platform 'bits'. There were a few problems with that: - The 'features' constants were only defined when exporting games. Not when building the game for running in the editor player. - If the project was built externally by an IDE, the constants wouldn't be defined at all. The new Sdk assigns default values to these constants when not built from the Godot editor, i.e.: when built from an IDE or from the command line. The default define constants are determined from the system MSBuild is running on. However, it's not possible for MSBuild to determine the set of supported engine features. It's also not possible to determine if a project is being built to run on a 32-bit or 64-bit Godot executable. As such the 'features' and 'bits' constants had to be removed. The benefit of checking those at compile time was questionable, and they can still be checked at runtime. The new list of define constants includes: - GODOT - GODOT_<PLATFORM> Defaults to the platform MSBuild is running on. - GODOT_<PC/MOBILE/WEB> - TOOLS When building with the 'Debug' configuration (editor and editor player). - GODOT_REAL_T_IS_DOUBLE Not defined by default unless $(GodotRealTIsDouble) is overriden to be 'true'. .NET Standard ------------- The target framework of game projects was changed to 'netstandard2.1'.