Commit graph

7 commits

Author SHA1 Message Date
Rémi Verschelde
0341251d0f
Bump version to 3.3-rc
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.).
2021-03-16 12:16:36 +01:00
Ignacio Etcheverry
a07589e2ad C#: Bump Godot.NET.Sdk version to 3.2.4 2020-12-06 01:12:10 +01:00
Ignacio Etcheverry
cd339ff002 C#: Remove ProjectTypeGuids from Godot.NET.Sdk
The property has no effect as the older VS project system doesn't
work with Sdk style projects.

The presence of the property was preventing Visual Studio for Mac
from opening the project if the Godot extension is not installed.
2020-12-06 01:12:10 +01:00
Ignacio Etcheverry
d639941446 C#: Fix targeting .NETFramework with Godot.NET.Sdk and .NET 5
Our target was overriding the official one, while not doing its job
assuming it was already taken care of...
2020-12-06 01:12:10 +01:00
Rémi Verschelde
9bbfa929bc
Mono: Fix typo in Godot.NET.Sdk.nuspec
Fixes #42666.

(cherry picked from commit 1af3cf15c2)
2020-10-19 16:09:59 +02:00
Rémi Verschelde
c8859f0463
Fix typos with codespell
Using codespell 1.17.1.

Method:
```
$ cat > ../godot-word-whitelist.txt << EOF
ang
curvelinear
dof
doubleclick
fave
findn
leapyear
lod
merchantibility
nd
numer
ois
ony
que
seeked
synching
te
uint
unselect
webp
EOF

$ codespell -w -q 3 -I ../godot-word-whitelist.txt --skip="./thirdparty,*.po"
$ git diff // undo unwanted changes
```
2020-09-18 14:09:51 +02:00
Ignacio Etcheverry
c3954441f3 3.2 New csproj style with backport 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).
2020-08-20 21:48:59 +02:00