Age | Commit message (Collapse) | Author |
|
|
|
Main benefits:
- Projects can be built offline. Previously you needed internet
access the first time building to download the packages.
- Changes to packages like Godot.NET.Sdk can be easily tested
before publishing. This was already possible but required
too many manual steps.
- First time builds are a bit faster, as the Sdk package doesn't
need to be downloaded. In practice, the package is very small
so it makes little difference.
Bumped Godot.NET.Sdk to 4.0.0-dev3 in order to enable the
recent changes regarding '.mono/' -> '.godot/mono/'.
|
|
- Removed item list that displayed multiple build
configurations launched. Now we only display
the last build that was launched.
- Display build output next to the issues list.
Its visibility can be toggled off/on.
This build output is obtained from the MSBuild
process rather than the MSBuild logger. As such
it displays some MSBuild fatal errors that
previously couldn't be displayed.
- Added a context menu to the issues list with
the option to copy the issue text.
- Replaced the 'Build Project' button in the panel
with a popup menu with the options:
- Build Solution
- Rebuild Solution
- Clean Solution
- The bottom panel button was renamed from 'Mono'
to 'MSBuild' and now display an error/warning icon
if the last build had issues.
|
|
Identifier "macOS" => "MacOS"
Platform/SDK name reverted to "osx"
|
|
Because `Strings OS_OSX::get_name() const` now returns "macOS" (15a9f94346c211b7afe96af500cb3405aabcf6b8)
The C# GodotTools were still using "OSX" as identifier a few things were borken (e.g. dotnet/msbuild detection).
|
|
|
|
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
```
|
|
When NormalizePath was called with an absolute
path (with drive letter) on Windows, it would
prepend a file path separator to the path, e.g.:
'\C:\Program Files\'.
Apparently this was still accepted as a valid
path by DotNetGlob and it stopped working when
we switched to MSBuildGlob.
|
|
At least on Windows there seems to be issues if
the solution has no BOM and contains a project
with cyrillic chars.
|
|
MSBuild Item returns empty strings if an attribute isn't set (which
caused an IndexOutOfRangeException in NormalizePath).
We were treating Excludes incorrectly, Remove directives provide the
intended behaviour in the auto-including csproj format.
|
|
C#: Hide Build button if there's no solution to build
|
|
Fix parsing of C# files with spaces in the path
|
|
C#: Fix Godot failing to find class namespace
|
|
Same as we do with the bottom panel. Mainly to
avoid bothering if the project is not using C#.
|
|
|
|
|
|
Previous condition checked only the host
platform. This was a problem as our official
builds are from Linux.
|
|
|
|
Support detecting both 32-bit and 64-bit installations of `vswhere.exe`.
|
|
|
|
C#: Save newly created csproj files without BOM
|
|
C#: Fix null exception in our MSBuild logger
|
|
|
|
|
|
We were removing invalid path characters from the
name in C++ code, but the C# editor code wasn't.
|
|
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.
|
|
Godot.NET.Sdk
-------------
Godot uses its own custom MSBuild Sdk for game
projects. This new Sdk adds its own functionality
on top of 'Microsoft.NET.Sdk'.
The new Sdk is resolved from the NuGet package.
All the default boilerplate was moved from game
projects to the Sdk. The default csproj for
game project can now be as simple as:
```
<Project Sdk="Godot.NET.Sdk/4.0.0-dev2">
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
</PropertyGroup>
</Project>
```
Source files are included by automatically so
Godot no longer needs to keep the csproj in sync
when creating new source files.
Define constants
----------------
Godot defines a list of constants for conditional
compilation. When exporting games, this list also
included engine 'features' and platform 'bits'.
There were a few problems with that:
- The 'features' constants were only defined when
exporting games. Not when building the game for
running in the editor player.
- If the project was built externally by an IDE,
the constants wouldn't be defined at all.
The new Sdk assigns default values to these
constants when not built from the Godot editor,
i.e.: when built from an IDE or from the command
line. The default define constants are determined
from the system MSBuild is running on.
However, it's not possible for MSBuild to
determine the set of supported engine features.
It's also not possible to determine if a project
is being built to run on a 32-bit or 64-bit
Godot executable.
As such the 'features' and 'bits' constants had
to be removed.
The benefit of checking those at compile time
was questionable, and they can still be checked
at runtime.
The new list of define constants includes:
- GODOT
- GODOT_<PLATFORM>
Defaults to the platform MSBuild is running on.
- GODOT_<PC/MOBILE/WEB>
- TOOLS
When building with the 'Debug' configuration
(editor and editor player).
- GODOT_REAL_T_IS_DOUBLE
Not defined by default unless $(GodotRealTIsDouble)
is overriden to be 'true'.
.NET Standard
-------------
The target framework of game projects was changed
to 'netstandard2.1'.
|
|
|
|
|
|
Fixed Mono not building after #39986 was merged due to a constant that got renamed.
|
|
Mono/C#: Fix InvalidCast because of attempt to unbox long as int
|
|
Documentation recommends not to use /t:restore
together with other targets (like /t:build),
as it messes with the environment.
|
|
|
|
fix underlying type of enum crashing cast in RiderPathManager
|
|
|
|
C#: Fix completion request with case insensitive resource path
|
|
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.
|
|
ToolButton has no redeeming differences with Button;
it's just a Button with the Flat property enabled by default.
Removing it avoids some confusion when creating GUIs.
Existing ToolButtons will be converted to Buttons, but the Flat
property won't be enabled automatically.
This closes https://github.com/godotengine/godot-proposals/issues/1081.
|
|
|
|
Simple fix for #38627. iOS (#20268) and HTML5 (#20270) removed from list of exceptions
for platforms supported in warning message.
|
|
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.
|
|
|
|
|
|
- Make GodotTools output directly to the SCons output directory.
- Removed xbuild_fallback from the build system.
|
|
This was a regression from 93d7ec88360a467a3041c0aa08390daa1f75892b (#38110).
Mono's old implementation of Microsoft.Build hardcodes HasUnsavedChanges to
always return true.
This workaround can be reverted once we switch to official Microsoft.Build.
|
|
C#: Save copy of sln and csproj before applying fixes
|
|
|
|
- Include PDB files in exported games.
- Release export templates also allow debugging now.
Right now the only way to enable debugging in exported games is with the environment variables, which may be cumbersome or not even possible on some platforms.
|
|
|
|
Right now, games only work on devices when exported with FullAOT+Interpreter.
There are some issues left that need to addressed for FullAOT alone. Right now,
it's giving issues with the Godot.NativeCalls static constructor.
|