3.2 New csproj style with backport of Godot.NET.Sdk

[neikeq]

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).

Fixes #30970
Fixes #41241

---

The 'Microsoft.Build' upgrade is needed in order to support reading and editing project files that use Sdks (which this PR introduces) as well as other new features.
A common example of issues with new features is having to specify a PackageReference version with a child element rather than the attribute. This is no longer the case now.
Fixes #15386

[akien-mga]

Thanks!

[akien-mga]

TargetFramework stays net472 both for new projects and when importing old ones. It can be manually changed to netstandard 2.0+ if desired though.

For .NET newbies like me, the corresponding moniker is netstandard2.1 as per https://docs.microsoft.com/en-us/dotnet/standard/frameworks

Tested locally on Windows with a pre-3.2.3 RC 5 build and it seems to work fine on the Dodge the Creeps C# demo. I was able to use C# 8.0 features like readonly struct members.

[ghost]

The new .csproj seems to enforce the use of the editor to create and move scripts and the ability to disable the "auto update project" option is gone. Is there a way to still be able to do all of this through the IDE without relying on the editor at any point ?

[neikeq]

@8nouk The new Sdk does not impose any of this. The project either includes the scripts automatically if the EnableDefaultCompileItems property is not disabled. Otherwise Godot takes care of adding the scripts to the csproj.