asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/modules/mono/glue/GodotSharp/GodotSharpEditor/GodotSharpEditor.csproj

27 lines
1.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 15:48:12 +02: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 19:12:32 +01: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 15:48:12 +02: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 19:12:32 +01:00
<RootNamespace>Godot</RootNamespace>
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 15:48:12 +02:00
<TargetFramework>netstandard2.1</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 19:12:32 +01: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 15:48:12 +02:00
<EnableDefaultItems>false</EnableDefaultItems>
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 19:12:32 +01: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 15:48:12 +02:00
<PropertyGroup>
<DefineConstants>$(DefineConstants);GODOT</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 19:12:32 +01: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 15:48:12 +02: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 19:12:32 +01:00
</ProjectReference>
</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 15:48:12 +02: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 19:12:32 +01:00
</Project>
Reference in a new issue Copy permalink