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

27 lines
1.1 KiB
XML
Raw Normal View History

3.2 New csproj style with backport of Godot.NET.Sdk This is a cherry-pick of ced77b1e9b5ffe0eb66de3d730d8583d12366c91 with several 3.2 specific alterations. There are a lot of build issues coming from old style projects. At this point fixing every single one of those would require adding patch after patch to the project file, which is a considerable amount work and makes the csproj even more bloated than it already is. As such I decided this effort would be better spent back-porting the Sdk style support that's already available in 4.0-dev to the 3.2 branch. This will prevent many issues, but it will also introduce other benefits, among them: - While target framework stays as .NET Framework v4.7.2, it can be changed to .NET Standard 2.0 or greater if desired. - It makes it much easier to add future patches. They are added to Godot.NET.Sdk and the only change required in Godot code is to update the Sdk version to use. - Default Godot define constants are also backported, which fixes IDE issues with the preprocessor. There are a few differences in the changes applied during patching of the csproj compared to 4.0 with the purpose of preventing breaking builds: - 'TargetFramework' stays net472 both for new projects and when importing old ones. It can be manually changed to netstandard 2.0+ if desired though. The following features are enabled by default for new projects. Enabling them in imported projects may result in errors that must be fixed manually: - 'EnableDefaultCompileItems' is disabled as it can result in undesired C# source files being included. Existing include items are kept. As long as 'EnableDefaultCompileItems' remains disabled, Godot will continue taking care of adding and removing C# files to the csproj. - 'GenerateAssemblyInfo' is disabled as it guarantees a build error because of conflicts between the existing 'AssemblyInfo.cs' and the auto-generated one. - 'Deterministic' is disabled because it doesn't like wildcards in the assembly version (1.0.*) that was in the old 'AssemblyInfo.cs'. Of importance: This is a breaking change. A great effort was put in avoiding build errors after upgrading a project, but there may still be exceptions. This also breaks forward compatibility. Projects opened with Godot 3.2.3 won't work out of the box with older Godot versions. This was already the case with changes introduced in 3.2.2. Albeit C# support in 3.2.x was still labeled as alpha, we've been trying to treat it as stable for some time. Still the amount of problems this change solves justifies it, but no more changes that break project compatibility are to be introduced from now on (at least for 3.x).
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>
3.2 New csproj style with backport of Godot.NET.Sdk This is a cherry-pick of ced77b1e9b5ffe0eb66de3d730d8583d12366c91 with several 3.2 specific alterations. There are a lot of build issues coming from old style projects. At this point fixing every single one of those would require adding patch after patch to the project file, which is a considerable amount work and makes the csproj even more bloated than it already is. As such I decided this effort would be better spent back-porting the Sdk style support that's already available in 4.0-dev to the 3.2 branch. This will prevent many issues, but it will also introduce other benefits, among them: - While target framework stays as .NET Framework v4.7.2, it can be changed to .NET Standard 2.0 or greater if desired. - It makes it much easier to add future patches. They are added to Godot.NET.Sdk and the only change required in Godot code is to update the Sdk version to use. - Default Godot define constants are also backported, which fixes IDE issues with the preprocessor. There are a few differences in the changes applied during patching of the csproj compared to 4.0 with the purpose of preventing breaking builds: - 'TargetFramework' stays net472 both for new projects and when importing old ones. It can be manually changed to netstandard 2.0+ if desired though. The following features are enabled by default for new projects. Enabling them in imported projects may result in errors that must be fixed manually: - 'EnableDefaultCompileItems' is disabled as it can result in undesired C# source files being included. Existing include items are kept. As long as 'EnableDefaultCompileItems' remains disabled, Godot will continue taking care of adding and removing C# files to the csproj. - 'GenerateAssemblyInfo' is disabled as it guarantees a build error because of conflicts between the existing 'AssemblyInfo.cs' and the auto-generated one. - 'Deterministic' is disabled because it doesn't like wildcards in the assembly version (1.0.*) that was in the old 'AssemblyInfo.cs'. Of importance: This is a breaking change. A great effort was put in avoiding build errors after upgrading a project, but there may still be exceptions. This also breaks forward compatibility. Projects opened with Godot 3.2.3 won't work out of the box with older Godot versions. This was already the case with changes introduced in 3.2.2. Albeit C# support in 3.2.x was still labeled as alpha, we've been trying to treat it as stable for some time. Still the amount of problems this change solves justifies it, but no more changes that break project compatibility are to be introduced from now on (at least for 3.x).
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>
3.2 New csproj style with backport of Godot.NET.Sdk This is a cherry-pick of ced77b1e9b5ffe0eb66de3d730d8583d12366c91 with several 3.2 specific alterations. There are a lot of build issues coming from old style projects. At this point fixing every single one of those would require adding patch after patch to the project file, which is a considerable amount work and makes the csproj even more bloated than it already is. As such I decided this effort would be better spent back-porting the Sdk style support that's already available in 4.0-dev to the 3.2 branch. This will prevent many issues, but it will also introduce other benefits, among them: - While target framework stays as .NET Framework v4.7.2, it can be changed to .NET Standard 2.0 or greater if desired. - It makes it much easier to add future patches. They are added to Godot.NET.Sdk and the only change required in Godot code is to update the Sdk version to use. - Default Godot define constants are also backported, which fixes IDE issues with the preprocessor. There are a few differences in the changes applied during patching of the csproj compared to 4.0 with the purpose of preventing breaking builds: - 'TargetFramework' stays net472 both for new projects and when importing old ones. It can be manually changed to netstandard 2.0+ if desired though. The following features are enabled by default for new projects. Enabling them in imported projects may result in errors that must be fixed manually: - 'EnableDefaultCompileItems' is disabled as it can result in undesired C# source files being included. Existing include items are kept. As long as 'EnableDefaultCompileItems' remains disabled, Godot will continue taking care of adding and removing C# files to the csproj. - 'GenerateAssemblyInfo' is disabled as it guarantees a build error because of conflicts between the existing 'AssemblyInfo.cs' and the auto-generated one. - 'Deterministic' is disabled because it doesn't like wildcards in the assembly version (1.0.*) that was in the old 'AssemblyInfo.cs'. Of importance: This is a breaking change. A great effort was put in avoiding build errors after upgrading a project, but there may still be exceptions. This also breaks forward compatibility. Projects opened with Godot 3.2.3 won't work out of the box with older Godot versions. This was already the case with changes introduced in 3.2.2. Albeit C# support in 3.2.x was still labeled as alpha, we've been trying to treat it as stable for some time. Still the amount of problems this change solves justifies it, but no more changes that break project compatibility are to be introduced from now on (at least for 3.x).
2020-07-20 13:48:12 +00:00
<TargetFramework>netstandard2.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>
3.2 New csproj style with backport of Godot.NET.Sdk This is a cherry-pick of ced77b1e9b5ffe0eb66de3d730d8583d12366c91 with several 3.2 specific alterations. There are a lot of build issues coming from old style projects. At this point fixing every single one of those would require adding patch after patch to the project file, which is a considerable amount work and makes the csproj even more bloated than it already is. As such I decided this effort would be better spent back-porting the Sdk style support that's already available in 4.0-dev to the 3.2 branch. This will prevent many issues, but it will also introduce other benefits, among them: - While target framework stays as .NET Framework v4.7.2, it can be changed to .NET Standard 2.0 or greater if desired. - It makes it much easier to add future patches. They are added to Godot.NET.Sdk and the only change required in Godot code is to update the Sdk version to use. - Default Godot define constants are also backported, which fixes IDE issues with the preprocessor. There are a few differences in the changes applied during patching of the csproj compared to 4.0 with the purpose of preventing breaking builds: - 'TargetFramework' stays net472 both for new projects and when importing old ones. It can be manually changed to netstandard 2.0+ if desired though. The following features are enabled by default for new projects. Enabling them in imported projects may result in errors that must be fixed manually: - 'EnableDefaultCompileItems' is disabled as it can result in undesired C# source files being included. Existing include items are kept. As long as 'EnableDefaultCompileItems' remains disabled, Godot will continue taking care of adding and removing C# files to the csproj. - 'GenerateAssemblyInfo' is disabled as it guarantees a build error because of conflicts between the existing 'AssemblyInfo.cs' and the auto-generated one. - 'Deterministic' is disabled because it doesn't like wildcards in the assembly version (1.0.*) that was in the old 'AssemblyInfo.cs'. Of importance: This is a breaking change. A great effort was put in avoiding build errors after upgrading a project, but there may still be exceptions. This also breaks forward compatibility. Projects opened with Godot 3.2.3 won't work out of the box with older Godot versions. This was already the case with changes introduced in 3.2.2. Albeit C# support in 3.2.x was still labeled as alpha, we've been trying to treat it as stable for some time. Still the amount of problems this change solves justifies it, but no more changes that break project compatibility are to be introduced from now on (at least for 3.x).
2020-07-20 13:48:12 +00: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 18:12:32 +00:00
</PropertyGroup>
3.2 New csproj style with backport of Godot.NET.Sdk This is a cherry-pick of ced77b1e9b5ffe0eb66de3d730d8583d12366c91 with several 3.2 specific alterations. There are a lot of build issues coming from old style projects. At this point fixing every single one of those would require adding patch after patch to the project file, which is a considerable amount work and makes the csproj even more bloated than it already is. As such I decided this effort would be better spent back-porting the Sdk style support that's already available in 4.0-dev to the 3.2 branch. This will prevent many issues, but it will also introduce other benefits, among them: - While target framework stays as .NET Framework v4.7.2, it can be changed to .NET Standard 2.0 or greater if desired. - It makes it much easier to add future patches. They are added to Godot.NET.Sdk and the only change required in Godot code is to update the Sdk version to use. - Default Godot define constants are also backported, which fixes IDE issues with the preprocessor. There are a few differences in the changes applied during patching of the csproj compared to 4.0 with the purpose of preventing breaking builds: - 'TargetFramework' stays net472 both for new projects and when importing old ones. It can be manually changed to netstandard 2.0+ if desired though. The following features are enabled by default for new projects. Enabling them in imported projects may result in errors that must be fixed manually: - 'EnableDefaultCompileItems' is disabled as it can result in undesired C# source files being included. Existing include items are kept. As long as 'EnableDefaultCompileItems' remains disabled, Godot will continue taking care of adding and removing C# files to the csproj. - 'GenerateAssemblyInfo' is disabled as it guarantees a build error because of conflicts between the existing 'AssemblyInfo.cs' and the auto-generated one. - 'Deterministic' is disabled because it doesn't like wildcards in the assembly version (1.0.*) that was in the old 'AssemblyInfo.cs'. Of importance: This is a breaking change. A great effort was put in avoiding build errors after upgrading a project, but there may still be exceptions. This also breaks forward compatibility. Projects opened with Godot 3.2.3 won't work out of the box with older Godot versions. This was already the case with changes introduced in 3.2.2. Albeit C# support in 3.2.x was still labeled as alpha, we've been trying to treat it as stable for some time. Still the amount of problems this change solves justifies it, but no more changes that break project compatibility are to be introduced from now on (at least for 3.x).
2020-07-20 13:48:12 +00: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 18:12:32 +00:00
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..\GodotSharp\GodotSharp.csproj">
3.2 New csproj style with backport of Godot.NET.Sdk This is a cherry-pick of ced77b1e9b5ffe0eb66de3d730d8583d12366c91 with several 3.2 specific alterations. There are a lot of build issues coming from old style projects. At this point fixing every single one of those would require adding patch after patch to the project file, which is a considerable amount work and makes the csproj even more bloated than it already is. As such I decided this effort would be better spent back-porting the Sdk style support that's already available in 4.0-dev to the 3.2 branch. This will prevent many issues, but it will also introduce other benefits, among them: - While target framework stays as .NET Framework v4.7.2, it can be changed to .NET Standard 2.0 or greater if desired. - It makes it much easier to add future patches. They are added to Godot.NET.Sdk and the only change required in Godot code is to update the Sdk version to use. - Default Godot define constants are also backported, which fixes IDE issues with the preprocessor. There are a few differences in the changes applied during patching of the csproj compared to 4.0 with the purpose of preventing breaking builds: - 'TargetFramework' stays net472 both for new projects and when importing old ones. It can be manually changed to netstandard 2.0+ if desired though. The following features are enabled by default for new projects. Enabling them in imported projects may result in errors that must be fixed manually: - 'EnableDefaultCompileItems' is disabled as it can result in undesired C# source files being included. Existing include items are kept. As long as 'EnableDefaultCompileItems' remains disabled, Godot will continue taking care of adding and removing C# files to the csproj. - 'GenerateAssemblyInfo' is disabled as it guarantees a build error because of conflicts between the existing 'AssemblyInfo.cs' and the auto-generated one. - 'Deterministic' is disabled because it doesn't like wildcards in the assembly version (1.0.*) that was in the old 'AssemblyInfo.cs'. Of importance: This is a breaking change. A great effort was put in avoiding build errors after upgrading a project, but there may still be exceptions. This also breaks forward compatibility. Projects opened with Godot 3.2.3 won't work out of the box with older Godot versions. This was already the case with changes introduced in 3.2.2. Albeit C# support in 3.2.x was still labeled as alpha, we've been trying to treat it as stable for some time. Still the amount of problems this change solves justifies it, but no more changes that break project compatibility are to be introduced from now on (at least for 3.x).
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>
3.2 New csproj style with backport of Godot.NET.Sdk This is a cherry-pick of ced77b1e9b5ffe0eb66de3d730d8583d12366c91 with several 3.2 specific alterations. There are a lot of build issues coming from old style projects. At this point fixing every single one of those would require adding patch after patch to the project file, which is a considerable amount work and makes the csproj even more bloated than it already is. As such I decided this effort would be better spent back-porting the Sdk style support that's already available in 4.0-dev to the 3.2 branch. This will prevent many issues, but it will also introduce other benefits, among them: - While target framework stays as .NET Framework v4.7.2, it can be changed to .NET Standard 2.0 or greater if desired. - It makes it much easier to add future patches. They are added to Godot.NET.Sdk and the only change required in Godot code is to update the Sdk version to use. - Default Godot define constants are also backported, which fixes IDE issues with the preprocessor. There are a few differences in the changes applied during patching of the csproj compared to 4.0 with the purpose of preventing breaking builds: - 'TargetFramework' stays net472 both for new projects and when importing old ones. It can be manually changed to netstandard 2.0+ if desired though. The following features are enabled by default for new projects. Enabling them in imported projects may result in errors that must be fixed manually: - 'EnableDefaultCompileItems' is disabled as it can result in undesired C# source files being included. Existing include items are kept. As long as 'EnableDefaultCompileItems' remains disabled, Godot will continue taking care of adding and removing C# files to the csproj. - 'GenerateAssemblyInfo' is disabled as it guarantees a build error because of conflicts between the existing 'AssemblyInfo.cs' and the auto-generated one. - 'Deterministic' is disabled because it doesn't like wildcards in the assembly version (1.0.*) that was in the old 'AssemblyInfo.cs'. Of importance: This is a breaking change. A great effort was put in avoiding build errors after upgrading a project, but there may still be exceptions. This also breaks forward compatibility. Projects opened with Godot 3.2.3 won't work out of the box with older Godot versions. This was already the case with changes introduced in 3.2.2. Albeit C# support in 3.2.x was still labeled as alpha, we've been trying to treat it as stable for some time. Still the amount of problems this change solves justifies it, but no more changes that break project compatibility are to be introduced from now on (at least for 3.x).
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>