asgardius/virtualx-engine
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
virtualx-engine/modules/mono/editor/GodotTools/GodotTools.ProjectEditor/GodotTools.ProjectEditor.csproj

35 lines
1.8 KiB
XML
Raw Normal View History

[3.2] C#: Support for building with the dotnet CLI By adding a reference to the 'Microsoft.NETFramework.ReferenceAssemblies' nuget package, we can build projects targeting .NET Framework with the dotnet CLI. By referencing this package we also don't need to install Mono on Linux/macOS or .NET Framework on Windows, as the assemblies are taken from the package.
2020-05-10 22:56:35 +02:00
<Project Sdk="Microsoft.NET.Sdk">
Added mono module
2017-10-02 23:24:00 +02:00
<PropertyGroup>
<ProjectGuid>{A8CDAD94-C6D4-4B19-A7E7-76C53CC92984}</ProjectGuid>
[3.2] C#: Support for building with the dotnet CLI By adding a reference to the 'Microsoft.NETFramework.ReferenceAssemblies' nuget package, we can build projects targeting .NET Framework with the dotnet CLI. By referencing this package we also don't need to install Mono on Linux/macOS or .NET Framework on Windows, as the assemblies are taken from the package.
2020-05-10 22:56:35 +02:00
<TargetFramework>net472</TargetFramework>
3.2 C#: Upgrade GodotTools to nuget Microsoft.Build This upgrade is needed in order to support reading and editing project files that use Sdks as well as other new features. A common example in 3.2 is having to specify a PackageReference version with a child element rather than the attribute. This is no longer the case now. Partial cherry-pick of f3bcd5f8dd36c4ce384f00a03650f71dce5c4de6 Most of the other changes from that commit were already partially cherry-picked in 3928fe200f1fda49655b429bd64f7bb55457c30d.
2020-08-20 12:56:36 +02:00
<LangVersion>7.2</LangVersion>
Added mono module
2017-10-02 23:24:00 +02:00
</PropertyGroup>
<ItemGroup>
<Reference Include="Microsoft.Build" />
3.2 C#: Upgrade GodotTools to nuget Microsoft.Build This upgrade is needed in order to support reading and editing project files that use Sdks as well as other new features. A common example in 3.2 is having to specify a PackageReference version with a child element rather than the attribute. This is no longer the case now. Partial cherry-pick of f3bcd5f8dd36c4ce384f00a03650f71dce5c4de6 Most of the other changes from that commit were already partially cherry-picked in 3928fe200f1fda49655b429bd64f7bb55457c30d.
2020-08-20 12:56:36 +02:00
<PackageReference Include="Microsoft.Build" Version="16.5.0" />
C#: Don't overwrite newer Godot.NET.Sdk patch version in csproj Allow game projects to use a Godot.NET.Sdk with a newer patch version. The major and minor version are still required to be the same. For example: Allow a Godot 3.2.4 C# project to use a hypothetical 3.2.5 version of Godot.NET.Sdk.
2020-12-06 00:56:47 +01:00
<PackageReference Include="semver" Version="2.0.6" />
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 15:48:12 +02:00
<PackageReference Include="JetBrains.Annotations" Version="2019.1.3.0" ExcludeAssets="runtime" PrivateAssets="all" />
[3.2] C#: Support for building with the dotnet CLI By adding a reference to the 'Microsoft.NETFramework.ReferenceAssemblies' nuget package, we can build projects targeting .NET Framework with the dotnet CLI. By referencing this package we also don't need to install Mono on Linux/macOS or .NET Framework on Windows, as the assemblies are taken from the package.
2020-05-10 22:56:35 +02:00
<PackageReference Include="Microsoft.NETFramework.ReferenceAssemblies" Version="1.0.0" PrivateAssets="All" />
Support globs in csproj includes
2018-10-22 19:20:29 +02:00
</ItemGroup>
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
<ItemGroup>
[3.2] C#: Support for building with the dotnet CLI By adding a reference to the 'Microsoft.NETFramework.ReferenceAssemblies' nuget package, we can build projects targeting .NET Framework with the dotnet CLI. By referencing this package we also don't need to install Mono on Linux/macOS or .NET Framework on Windows, as the assemblies are taken from the package.
2020-05-10 22:56:35 +02:00
<ProjectReference Include="..\GodotTools.Core\GodotTools.Core.csproj" />
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
</ItemGroup>
C#: Fix 'Parameter toolsPath cannot be null' error (cherry picked from commit 2bd6252e92d6f4fe51e0d7e50be41ea20d6d59d7)
2020-08-24 11:24:05 +02:00
<!--
The Microsoft.Build.Runtime package is too problematic so we create a MSBuild.exe stub. The workaround described
here doesn't work with Microsoft.NETFramework.ReferenceAssemblies: https://github.com/microsoft/msbuild/issues/3486
We need a MSBuild.exe file as there's an issue in Microsoft.Build where it executes platform dependent code when
searching for MSBuild.exe before the fallback to not using it. A stub is fine as it should never be executed.
-->
3.2 C#: Upgrade GodotTools to nuget Microsoft.Build This upgrade is needed in order to support reading and editing project files that use Sdks as well as other new features. A common example in 3.2 is having to specify a PackageReference version with a child element rather than the attribute. This is no longer the case now. Partial cherry-pick of f3bcd5f8dd36c4ce384f00a03650f71dce5c4de6 Most of the other changes from that commit were already partially cherry-picked in 3928fe200f1fda49655b429bd64f7bb55457c30d.
2020-08-20 12:56:36 +02:00
<ItemGroup>
<None Include="MSBuild.exe" CopyToOutputDirectory="Always" />
</ItemGroup>
C#: Fix Windows detection for copying MSBuild stub Previous condition checked only the host platform. This was a problem as our official builds are from Linux. (cherry picked from commit 206501a45e2219e4013ff1fb4ae98311aa5afaad)
2020-09-03 09:08:58 +02:00
<Target Name="CopyMSBuildStubWindows" AfterTargets="Build" Condition=" '$(GodotPlatform)' == 'windows' Or ( '$(GodotPlatform)' == '' And '$(OS)' == 'Windows_NT' ) ">
C#: Fix 'Parameter toolsPath cannot be null' error (cherry picked from commit 2bd6252e92d6f4fe51e0d7e50be41ea20d6d59d7)
2020-08-24 11:24:05 +02:00
<PropertyGroup>
<GodotSourceRootPath>$(SolutionDir)/../../../../</GodotSourceRootPath>
<GodotOutputDataDir>$(GodotSourceRootPath)/bin/GodotSharp</GodotOutputDataDir>
</PropertyGroup>
<!-- Need to copy it here as well on Windows -->
<Copy SourceFiles="MSBuild.exe" DestinationFiles="$(GodotOutputDataDir)\Mono\lib\mono\v4.0\MSBuild.exe" />
</Target>
Re-write mono module editor code in C# Make the build system automatically build the C# Api assemblies to be shipped with the editor. Make the editor, editor player and debug export templates use Api assemblies built with debug symbols. Always run MSBuild to build the editor tools and Api assemblies when building Godot. Several bugs fixed related to assembly hot reloading and restoring state. Fix StringExtensions internal calls not being registered correctly, resulting in MissingMethodException.
2019-07-03 09:44:53 +02:00
</Project>
Reference in a new issue Copy permalink