Commit graph

27 commits

Author SHA1 Message Date
Ignacio Roldán Etcheverry 50b603c7dc C#: Begin move to .NET Core
We're targeting .NET 5 for now to make development easier while
.NET 6 is not yet released.

TEMPORARY REGRESSIONS
---------------------

Assembly unloading is not implemented yet. As such, many Godot
resources are leaked at exit. This will be re-implemented later
together with assembly hot-reloading.
2021-09-22 08:27:12 +02:00
Ignacio Roldán Etcheverry f744d99179 C#: Restructure code prior move to .NET Core
The main focus here was to remove the majority of code that relied on
Mono's embedding APIs, specially the reflection APIs. The embedding
APIs we still use are the bare minimum we need for things to work.
A lot of code was moved to C#. We no longer deal with any managed
objects (`MonoObject*`, and such) in native code, and all marshaling
is done in C#.

The reason for restructuring the code and move away from embedding APIs
is that once we move to .NET Core, we will be limited by the much more
minimal .NET hosting.

PERFORMANCE REGRESSIONS
-----------------------

Some parts of the code were written with little to no concern about
performance. This includes code that calls into script methods and
accesses script fields, properties and events.
The reason for this is that all of that will be moved to source
generators, so any work prior to that would be a waste of time.

DISABLED FEATURES
-----------------

Some code was removed as it no longer makes sense (or won't make sense
in the future).
Other parts were commented out with `#if 0`s and TODO warnings because
it doesn't make much sense to work on them yet as those parts will
change heavily when we switch to .NET Core but also when we start
introducing source generators.
As such, the following features were disabled temporarily:
- Assembly-reloading (will be done with ALCs in .NET Core).
- Properties/fields exports and script method listing (will be
  handled by source generators in the future).
- Exception logging in the editor and stack info for errors.
- Exporting games.
- Building of C# projects. We no longer copy the Godot API assemblies
  to the project directory, so MSBuild won't be able to find them. The
  idea is to turn them into NuGet packages in the future, which could
  also be obtained from local NuGet sources during development.
2021-09-22 06:38:00 +02:00
Raul Santos accd05f4ad Use Array.Empty instead of allocating a every time
Use `System.Array.Empty<T>` to get an empty array instead of allocating
a new one every time. Since arrays are immutable there is no need to
allocate them every time.
2021-07-26 03:52:31 +02:00
Ignacio Etcheverry e2afe700f6 Add C# source generator for a new ScriptPath attribute
This source generator adds a newly introduced attribute,
`ScriptPath` to all classes that:

- Are top-level classes (not inner/nested).
- Have the `partial` modifier.
- Inherit `Godot.Object`.
- The class name matches the file name.

A build error is thrown if the generator finds a class that meets these
conditions but is not declared `partial`, unless the class is annotated
with the `DisableGodotGenerators` attribute.

We also generate an `AssemblyHasScripts` assembly attribute which Godot
uses to get all the script classes in the assembly, eliminating the need
for Godot to search them. We can also avoid searching in assemblies that
don't have this attribute. This will be good for performance in the
future once we support multiple assemblies with Godot script classes.

This is an example of what the generated code looks like:

```
using Godot;
namespace Foo {
	[ScriptPathAttribute("res://Player.cs")]
	// Multiple partial declarations are allowed
	[ScriptPathAttribute("res://Foo/Player.cs")]
	partial class Player {}
}

[assembly:AssemblyHasScripts(new System.Type[] { typeof(Foo.Player) })]
```

The new attributes replace script metadata which we were generating by
determining the namespace of script classes with a very simple parser.
This fixes several issues with the old approach related to parser
errors and conditional compilation.
It also makes the task part of the MSBuild project build, rather than
a separate step executed by the Godot editor.
2021-03-06 21:50:32 +01:00
Ignacio Etcheverry b98e8b11e6 Mono: Add extra WASM framework assemblies on game export
This is needed with newer Mono versions, at least with Mono 6.12+

Depends on the following commit from our build scripts:
godotengine/godot-mono-builds@9d75cff174
2020-12-14 20:55:29 +01:00
Ignacio Etcheverry f06f91281c C#: Re-work solution build output panel
- 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.
2020-10-23 07:49:39 +02:00
Lorenz Junglas 7e2b495435 Adressed Review
Identifier "macOS" => "MacOS"
Platform/SDK name reverted to "osx"
2020-10-08 13:51:19 +02:00
Lorenz Junglas 519f369795 C# GodotTools: Replace platform Identifier "OSX" with "macOS"
Because `Strings OS_OSX::get_name() const` now returns "macOS" (15a9f94346)
The C# GodotTools were still using "OSX" as identifier a few things were borken (e.g. dotnet/msbuild detection).
2020-10-08 13:51:19 +02:00
Ignacio Etcheverry 99740850a2 C#: Fix InvalidCastException on export 2020-08-30 01:55:21 +02:00
Ignacio Etcheverry 8bb48ae57a Mono/C#: Fix editor using wrong project assembly path in rare cases
We were removing invalid path characters from the
name in C++ code, but the C# editor code wasn't.
2020-08-21 01:42:47 +02:00
Ignacio Etcheverry ced77b1e9b C#: Switch games to MSBuild Sdks and .NET Standard
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'.
2020-07-25 19:22:01 +02:00
Ignacio Etcheverry f3bcd5f8dd C#: Use Sdks in GodotTools csprojs and switch to nuget Microsoft.Build 2020-05-09 21:36:31 +02:00
Ignacio Etcheverry 71fc87e101 Mono/C#: Allow debugging exported games
- 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.
2020-04-22 16:44:03 +02:00
Ignacio Etcheverry 77dd061345 Mono/C#: Add iOS support
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.
2020-03-31 09:37:16 +02:00
Ignacio Etcheverry 40f8de4c1e Sync csproj when files are changed from the Godot FileSystem dock 2020-03-18 15:06:41 +01:00
Ignacio Etcheverry 1b634785b5 C#: Replace uses of old Configuration and update old csprojs 2020-03-14 19:01:29 +01:00
Ignacio Etcheverry 59ec19d5a8 Mono/C#: Add setting to include I18N assemblies in the exported game 2020-01-23 17:47:09 +01:00
Ignacio Etcheverry 98dc07f25f Mono/C#: Fix Variant -> MonoString* when type is Variant:NIL
`Variant::operator String()` returns "Null" if the type is `Variant:NIL`.
We must consider that and return a null `MonoString*` instead when marshalling.
This was also causing a "Null" error to be displayed when exporting a game
because null string members would be set to "Null" during hot-reload.
2019-12-19 16:51:32 +01:00
Ignacio Etcheverry 20d7013c60 Mono/C#: Fix project export and fix FindLast/GetFile regression
d09193b08a introduced a regression in
StringExtensions.FindLast. StringExtensions.GetFile was also affected as it
relies on FindLast. This in turn broke the project exporter as it uses GetFile.
The cause of the regression is that now FindLast is calling LastIndexOf
with 'startIndex: 0'. This should be 'startIndex: str.Length - 1' instead.

Also fixed another regression in the project exporter:
de7c2ad21b moved 'GodotTools/GodotSharpExport.cs'
to 'GodotTools/Export/ExportPlugin.cs' and in doing so accidently reverted
the changes from commit e439581198.
2019-12-17 13:06:41 +01:00
Aaron Franke 5771f9959c
Mono formatting
No space for casting, add spaces inside braces, 4 space indentation, remove trailing indentation, remove BOM.
2019-12-11 16:32:47 -05:00
Ignacio Roldán Etcheverry 6544a0e908
Merge pull request #34018 from dsge/show-template-directory-path-in-error-message
Make sure to include the path in the "Data template directory not found" error message
2019-12-05 14:17:23 +01:00
Ignacio Etcheverry 066ae9d83b Mono/C#: Several android fixes
- Added correct config file for android dllmaps.
- Fix __Internal DllImports with a dlopen fallback.
- Add missing P/Invoke functions and internal calls expected by the monodroid BCL and our custom version of the 'Android.Runtime.AndroidEnvironment' class (this last one can be found in the godot-mono-builds repo).
- Make sure to set 'btls' instead of 'legacy' as the default TLS provider on Android.
2019-12-04 19:03:42 +01:00
dsge 81cae314b4 Make sure to include the path in the "Data template directory not found" error message 2019-11-30 15:44:18 +01:00
Ignacio Etcheverry 66de28eda8 Mono/C#: Add option to export assemblies outside of PCK
When using this options, assemblies will be saved in the Assemblies folder of the  data directory: 'data_AppName/Assemblies/'.
2019-11-29 00:36:05 +01:00
Ignacio Etcheverry d79aeca599 Fix C# export error dialog showing up when it should not 2019-11-20 13:07:26 +01:00
Ignacio Etcheverry 2b67924a0b Mono/C#: Initial exporter support for AOT compilation 2019-11-15 03:22:18 +01:00
Ignacio Etcheverry de7c2ad21b Mono/C#: WebAssembly support 2019-11-13 21:41:11 +01:00