We decided to rename the upcoming 3.2.4 release to 3.3 to better reflect that
it is a significant feature release, and not a maintenance update.
The `3.2` branch was also renamed to `3.x` and will now be the development
branch for future 3.x releases (3.3, 3.4, etc.).
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.
This is a cherry-pick of
ced77b1e9b
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).
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.
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.
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.
