godotengine
/
godot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
godot/modules/mono/glue/GodotSharp/GodotSharpEditor/GodotSharpEditor.csproj

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

49 lines
2.1 KiB
XML
Raw Normal View History

C#: Switch games to MSBuild Sdks and .NET Standard 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'.
2020-07-20 13:48:12 +00:00
<Project Sdk="Microsoft.NET.Sdk">
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 18:12:32 +00:00
<PropertyGroup>
<ProjectGuid>{8FBEC238-D944-4074-8548-B3B524305905}</ProjectGuid>
<OutputPath>bin/$(Configuration)</OutputPath>
C#: Switch games to MSBuild Sdks and .NET Standard 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'.
2020-07-20 13:48:12 +00:00
<AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath>
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 18:12:32 +00:00
<RootNamespace>Godot</RootNamespace>
C#: Upgrade to .NET 6 (5.0 -> 6.0)
2022-02-27 20:57:50 +00:00
<TargetFramework>net6.0</TargetFramework>
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 18:12:32 +00:00
<DocumentationFile>$(OutputPath)/$(AssemblyName).xml</DocumentationFile>
C#: Switch games to MSBuild Sdks and .NET Standard 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'.
2020-07-20 13:48:12 +00:00
<EnableDefaultItems>false</EnableDefaultItems>
C#: Move marshaling logic and generated glue to C# We will be progressively moving most code to C#. The plan is to only use Mono's embedding APIs to set things at launch. This will make it much easier to later support CoreCLR too which doesn't have rich embedding APIs. Additionally the code in C# is more maintainable and makes it easier to implement new features, e.g.: runtime codegen which we could use to avoid using reflection for marshaling everytime a field, property or method is accessed. SOME NOTES ON INTEROP We make the same assumptions as GDNative about the size of the Godot structures we use. We take it a bit further by also assuming the layout of fields in some cases, which is riskier but let's us squeeze out some performance by avoiding unnecessary managed to native calls. Code that deals with native structs is less safe than before as there's no RAII and copy constructors in C#. It's like using the GDNative C API directly. One has to take special care to free values they own. Perhaps we could use roslyn analyzers to check this, but I don't know any that uses attributes to determine what's owned or borrowed. As to why we maily use pointers for native structs instead of ref/out: - AFAIK (and confirmed with a benchmark) ref/out are pinned during P/Invoke calls and that has a cost. - Native struct fields can't be ref/out in the first place. - A `using` local can't be passed as ref/out, only `in`. Calling a method or property on an `in` value makes a silent copy, so we want to avoid `in`. REGARDING THE BUILD SYSTEM There's no longer a `mono_glue=yes/no` SCons options. We no longer need to build with `mono_glue=no`, generate the glue and then build again with `mono_glue=yes`. We build only once and generate the glue (which is in C# now). However, SCons no longer builds the C# projects for us. Instead one must run `build_assemblies.py`, e.g.: ```sh %godot_src_root%/modules/mono/build_scripts/build_assemblies.py \ --godot-output-dir=%godot_src_root%/bin \ --godot-target=release_debug` ``` We could turn this into a custom build target, but I don't know how to do that with SCons (it's possible with Meson). OTHER NOTES Most of the moved code doesn't follow the C# naming convention and still has the word Mono in the names despite no longer dealing with Mono's embedding APIs. This is just temporary while transitioning, to make it easier to understand what was moved where.
2021-05-03 13:21:06 +00:00
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>
C#: Upgrade to .NET 6 (5.0 -> 6.0)
2022-02-27 20:57:50 +00:00
<LangVersion>10</LangVersion>
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 18:12:32 +00:00
</PropertyGroup>
C#: Make GodotSharp API a NuGet package In the past, the Godot editor distributed the API assemblies and copied them to project directories for projects to reference them. This changed with the move to .NET 5/6. Godot no longer copies the assemblies to project directories. However, the project Sdk still tried to reference them from the same location. From now on, the GodotSharp API is distributed as a NuGet package, which the Sdk can reference. Added an option to `build_assemblies.py` to copy all Godot NuGet packages to an existing local NuGet source. This will be needed during development, while packages are not published to a remote NuGet repository. This option also makes sure to remove packages of the same version installed (~/.nuget/packages). Very useful during development, when packages change, to make sure the package being used by a project is the same we just built and not one from a previous build. A local NuGet source can be created like this: ``` mkdir ~/MyLocalNuGetSource && \ dotnet nuget add source ~/MyLocalNuGetSource/ -n MyLocalNuGetSource ```
2022-02-27 20:57:53 +00:00
<PropertyGroup>
<Description>Godot C# Editor API.</Description>
<Authors>Godot Engine contributors</Authors>
<PackageId>GodotSharpEditor</PackageId>
Bump version to 4.2-dev Keep on waitin'
2023-07-05 20:07:03 +00:00
<Version>4.2.0</Version>
C#: Make GodotSharp API a NuGet package In the past, the Godot editor distributed the API assemblies and copied them to project directories for projects to reference them. This changed with the move to .NET 5/6. Godot no longer copies the assemblies to project directories. However, the project Sdk still tried to reference them from the same location. From now on, the GodotSharp API is distributed as a NuGet package, which the Sdk can reference. Added an option to `build_assemblies.py` to copy all Godot NuGet packages to an existing local NuGet source. This will be needed during development, while packages are not published to a remote NuGet repository. This option also makes sure to remove packages of the same version installed (~/.nuget/packages). Very useful during development, when packages change, to make sure the package being used by a project is the same we just built and not one from a previous build. A local NuGet source can be created like this: ``` mkdir ~/MyLocalNuGetSource && \ dotnet nuget add source ~/MyLocalNuGetSource/ -n MyLocalNuGetSource ```
2022-02-27 20:57:53 +00:00
<PackageVersion>$(PackageVersion_GodotSharp)</PackageVersion>
<RepositoryUrl>https://github.com/godotengine/godot/tree/master/modules/mono/glue/GodotSharp/GodotSharpEditor</RepositoryUrl>
<PackageProjectUrl>$(RepositoryUrl)</PackageProjectUrl>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
C#: Generate symbols packages
2022-10-08 10:26:04 +00:00
<IncludeSymbols>true</IncludeSymbols>
<SymbolPackageFormat>snupkg</SymbolPackageFormat>
C#: Make GodotSharp API a NuGet package In the past, the Godot editor distributed the API assemblies and copied them to project directories for projects to reference them. This changed with the move to .NET 5/6. Godot no longer copies the assemblies to project directories. However, the project Sdk still tried to reference them from the same location. From now on, the GodotSharp API is distributed as a NuGet package, which the Sdk can reference. Added an option to `build_assemblies.py` to copy all Godot NuGet packages to an existing local NuGet source. This will be needed during development, while packages are not published to a remote NuGet repository. This option also makes sure to remove packages of the same version installed (~/.nuget/packages). Very useful during development, when packages change, to make sure the package being used by a project is the same we just built and not one from a previous build. A local NuGet source can be created like this: ``` mkdir ~/MyLocalNuGetSource && \ dotnet nuget add source ~/MyLocalNuGetSource/ -n MyLocalNuGetSource ```
2022-02-27 20:57:53 +00:00
</PropertyGroup>
C#: Switch games to MSBuild Sdks and .NET Standard 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'.
2020-07-20 13:48:12 +00:00
<PropertyGroup>
<DefineConstants>$(DefineConstants);GODOT</DefineConstants>
Add float arg to build_assemblies.py
2022-09-02 17:08:40 +00:00
<DefineConstants Condition=" '$(GodotFloat64)' == 'true' ">REAL_T_IS_DOUBLE;$(DefineConstants)</DefineConstants>
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 18:12:32 +00:00
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\GodotSharp\GodotSharp.csproj">
C#: Switch games to MSBuild Sdks and .NET Standard 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'.
2020-07-20 13:48:12 +00:00
<Private>false</Private>
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 18:12:32 +00:00
</ProjectReference>
</ItemGroup>
C#: Add compat overloads
2023-06-08 19:18:49 +00:00
<!-- Compat Sources -->
<ItemGroup>
<Compile Include="Compat.cs" />
</ItemGroup>
C#: Switch games to MSBuild Sdks and .NET Standard 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'.
2020-07-20 13:48:12 +00:00
<!--
We import a props file with auto-generated includes. This works well with Rider.
However, Visual Studio and MonoDevelop won't list them in the solution explorer.
We can't use wildcards as there may be undesired old files still hanging around.
Fortunately code completion, go to definition and such still work.
-->
<Import Project="Generated\GeneratedIncludes.props" />
Mono/C#: Re-structure API solution and GodotTools post-build target Previously we had a placeholder solution called 'Managed' to benefit from tooling while editing the a part of the C# API. Later the bindings generator would create the final 'GodotSharp' solution including these C# files as well as the auto-generated C# API. Now we replaced the 'Managed' solution with the final 'GodotSharp' solution which is no longer auto-generated, and the bindings generator only takes care of the auto-generated C# API. This has the following benefits: - It's less confusing as there will no longer be two versions of the same file (the original and a generated copy of it). Now there's only one. - We no longer need placeholder for auto-generated API classes, like Node or Resource. We used them for benefiting from tooling. Now we can just use the auto-generated API itself. - Simplifies the build system and bindings generator. Removed lot of code that is not needed anymore. Also added a post-build target to the GodotTools project to copy the output to the data dir. This makes it easy to iterate when doing changes to GodotTools, as SCons doesn't have to be executed anymore just to copy these new files.
2019-12-28 18:12:32 +00:00
</Project>