This error was normally being printed when
trying to open the project assembly while
the project was not yet built.
The error should not be printed. It's the job
of this method's caller to decide whether to
print an error or not if loading failed.
The editor wasn't clearing the debugger agent
settings properly after a processing a play
request from an IDE. This caused consequent play
attempts to fail if not launched from the IDE,
as the game would still attempt and fail to
connect to the debugger.
The concrete cause: Forgetting to clear the
`GODOT_MONO_DEBUGGER_AGENT` environment variable.
(cherry picked from commit 6e7da72648)
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).
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 f3bcd5f8dd
Most of the other changes from that commit were already partially
cherry-picked in 3928fe200f.
Not sure if we should check revision too, but this is good enough for what we want.
This will be needed to load the correct Microsoft.Build when we switch to the nuget version.
Manual cherry-pick of af4acb5b11 (relevant parts)
This change avoids the editor to freeze for several seconds when a
project with lots of scripts is loaded in the editor.
It focuses on a few heavy operations previously executed on all
previously loaded scripts:
- Initialize script resource (script validation/parsing) only
on focus
- ScriptTextEditor: code editor and edit menu are added to the
scene only on focus
- Add to recent scripts only when opening new scripts
(load/save scene metadata)
My initial attempt changed this in the gdscript code, which resulted in
a duplicate warning name in the builtin editor. We should just append
the warning name in the LSP instead.
This uses parens to match what is shown in the builtin editor.
(cherry picked from commit 8dcc39ec91)
Occasionally you want to ignore a warning with a `warning-ignore`
comment, and you have to go into the settings to look up what the
actual name of the warning is. This patch appends the warning name to
the end of the warning so you know what string to use to ignore it,
similar to other linters like pylint.
For example
```
"The signal 'blah' is declared but never emitted.";
```
is now
```
"The signal 'blah' is declared but never emitted. (UNUSED_SIGNAL)";
```
(cherry picked from commit de3ad3b30e)
fix crash when pass null in print array in GD.print 2
fix crash when pass null in print array in GD.print 3
fix space
(cherry picked from commit d2461bad63)
For some reason `mono_unhandled_exception` is not
printing the exception as its comment claims.
Use `mono_print_unhandled_exception` instead.
(cherry picked from commit f87ae395ee)
Sometimes Visual Studio documents have the root path all in upper case.
Since Godot doesn't support loading resource files with a case insensitive path,
this makes script resource loading to fail when the Godot editor gets code
completion requests from Visual Studio.
This fix allows the resource path part of the path to be case insensitive. It
still doesn't support cases where the rest of the path is also case insensitive.
For that we would need a proper API for comparing paths. However, this fix
should be enough for our current cases.
MSDN says:
> When you write .dds files, you should set the DDSD_CAPS and
> DDSD_PIXELFORMAT flags, and for mipmapped textures you should also
> set the DDSD_MIPMAPCOUNT flag. However, when you read a .dds file,
> you should not rely on the DDSD_CAPS, DDSD_PIXELFORMAT, and
> DDSD_MIPMAPCOUNT flags being set because some writers of such a file
> might not set these flags.
https://docs.microsoft.com/en-us/windows/win32/direct3ddds/dds-header
¯\_(ツ)_/¯
Fixes#39516.
(cherry picked from commit 0f21249a2d)
