asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/modules/mono/editor/Godot.NET.Sdk/Godot.NET.Sdk.sln

35 lines
2.3 KiB
Text
Raw Normal View History

C#: Begin move to .NET Core We're targeting .NET 5 for now to make development easier while .NET 6 is not yet released. TEMPORARY REGRESSIONS --------------------- Assembly unloading is not implemented yet. As such, many Godot resources are leaked at exit. This will be re-implemented later together with assembly hot-reloading.
2021-09-12 20:23:05 +02:00
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
Microsoft Visual Studio Solution File, Format Version 12.00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Godot.NET.Sdk", "Godot.NET.Sdk\Godot.NET.Sdk.csproj", "{31B00BFA-DEA1-42FA-A472-9E54A92A8A5F}"
EndProject
Add C# source generator for a new ScriptPath attribute 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.
2021-03-06 00:12:42 +01:00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Godot.SourceGenerators", "Godot.SourceGenerators\Godot.SourceGenerators.csproj", "{32D31B23-2A45-4099-B4F5-95B4C8FF7D9F}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Godot.SourceGenerators.Sample", "Godot.SourceGenerators.Sample\Godot.SourceGenerators.Sample.csproj", "{7297A614-8DF5-43DE-9EAD-99671B26BD1F}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "GodotSharp", "..\..\glue\GodotSharp\GodotSharp\GodotSharp.csproj", "{AEBF0036-DA76-4341-B651-A3F2856AB2FA}"
EndProject
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
Global
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Any CPU = Debug|Any CPU
Release|Any CPU = Release|Any CPU
EndGlobalSection
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{31B00BFA-DEA1-42FA-A472-9E54A92A8A5F}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{31B00BFA-DEA1-42FA-A472-9E54A92A8A5F}.Debug|Any CPU.Build.0 = Debug|Any CPU
{31B00BFA-DEA1-42FA-A472-9E54A92A8A5F}.Release|Any CPU.ActiveCfg = Release|Any CPU
{31B00BFA-DEA1-42FA-A472-9E54A92A8A5F}.Release|Any CPU.Build.0 = Release|Any CPU
Add C# source generator for a new ScriptPath attribute 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.
2021-03-06 00:12:42 +01:00
{32D31B23-2A45-4099-B4F5-95B4C8FF7D9F}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{32D31B23-2A45-4099-B4F5-95B4C8FF7D9F}.Debug|Any CPU.Build.0 = Debug|Any CPU
{32D31B23-2A45-4099-B4F5-95B4C8FF7D9F}.Release|Any CPU.ActiveCfg = Release|Any CPU
{32D31B23-2A45-4099-B4F5-95B4C8FF7D9F}.Release|Any CPU.Build.0 = Release|Any CPU
{7297A614-8DF5-43DE-9EAD-99671B26BD1F}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{7297A614-8DF5-43DE-9EAD-99671B26BD1F}.Debug|Any CPU.Build.0 = Debug|Any CPU
{7297A614-8DF5-43DE-9EAD-99671B26BD1F}.Release|Any CPU.ActiveCfg = Release|Any CPU
{7297A614-8DF5-43DE-9EAD-99671B26BD1F}.Release|Any CPU.Build.0 = Release|Any CPU
{AEBF0036-DA76-4341-B651-A3F2856AB2FA}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
{AEBF0036-DA76-4341-B651-A3F2856AB2FA}.Debug|Any CPU.Build.0 = Debug|Any CPU
{AEBF0036-DA76-4341-B651-A3F2856AB2FA}.Release|Any CPU.ActiveCfg = Release|Any CPU
{AEBF0036-DA76-4341-B651-A3F2856AB2FA}.Release|Any CPU.Build.0 = Release|Any CPU
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
EndGlobalSection
EndGlobal
Reference in a new issue Copy permalink