Commit graph

29 commits

Author SHA1 Message Date
Aaron Franke 5f8275d9ac
Add a simple C# .editorconfig 2021-07-23 17:04:53 -04: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 64b5ee7010 C#: Make editor create NuGet fallback folder for Godot packages
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/'.
2020-10-23 10:54:49 +02:00
Ignacio Etcheverry 1c74fa4242 C#: Use BOM when creating a solution
At least on Windows there seems to be issues if
the solution has no BOM and contains a project
with cyrillic chars.
2020-09-08 20:06:07 +02:00
Alex de la Mare 8dbd7155b5 Handle csproj "Remove" globs
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.
2020-09-06 11:34:04 +10:00
Ignacio Etcheverry 206501a45e C#: Fix Windows detection for copying MSBuild stub
Previous condition checked only the host
platform. This was a problem as our official
builds are from Linux.
2020-09-03 09:09:04 +02:00
Ignacio Etcheverry 2bd6252e92 C#: Fix 'Parameter toolsPath cannot be null' error 2020-08-24 11:24:08 +02:00
Ignacio Etcheverry b5f6285f34 C#: Save newly created csproj files without BOM 2020-08-21 01:48:56 +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 54df72dcc6 C#: Add VisualStudio support 2020-06-15 21:29:16 +02:00
Ignacio Etcheverry dcf1dc4fe0 C#: Support for building with the dotnet CLI
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.
2020-05-11 08:17:37 +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 81f13f6171 C#: Fix always saving copy of csproj even with no changes
This was a regression from 93d7ec8836 (#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.
2020-04-23 16:18:55 +02:00
Ignacio Etcheverry 93d7ec8836 C#: Save copy of sln and csproj before applying fixes 2020-04-22 16:50:43 +02:00
Aaron Franke 7dbe8b65ae
Make file formatting comply with POSIX and Unix standards
UTF-8, LF, no BOM, and newlines at the end of files
2020-03-21 17:41:03 -04: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
Ivan Shakhov ce01b83c4a reorder solution configurations + migration 2020-03-11 17:22:12 +01:00
Ignacio Etcheverry d9ff5f7fc2 Mono/C#: Default to net47 for new projects 2020-01-23 15:57:47 +01:00
Ignacio Etcheverry 9ce0ddcf0d Mono/C#: Fix wrong HintPath for package in GodotTools 2020-01-03 15:53:16 +01:00
Ignacio Roldán Etcheverry 7fddf5eb7c
Merge pull request #34699 from van800/godot-guid
Custom property for Godot generated project
2019-12-31 20:28:14 +01:00
Ivan Shakhov af2e6e12d1 add custom property to csproj, which identifies that project is generated by Godot 2019-12-30 16:16:47 +01:00
Ignacio Etcheverry 86274b9fc9 Mono/C#: Re-structure API solution and GodotTools post-build target
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.
2019-12-28 20:48:55 +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 Etcheverry 6d2883c9bf Fix GodotTools.ProjectEditor HintPaths for referenced packages 2019-08-29 18:19:01 +02:00
Ignacio Etcheverry 3af8bd071e Set C# 7 as LangVersion for GodotTools and Godot API projects
This will make it harder for someone to accidentally commit code that requires a newer version.
2019-08-25 15:53:47 +02:00
Ignacio Etcheverry 4e84478f4e Fix incorrectly updating csproj and not closing build issues file 2019-07-25 21:06:40 +02:00
Ignacio Etcheverry 9eb0729a05 Mono: Fix Api HintPath and update old game projects
Fixed Api assembly references with more than one HintPath.
Also made the editor update old C# projects use the new Api assembly HintPaths.
2019-07-10 22:00:31 +02:00
Ignacio Etcheverry 270af6fa08 Re-write mono module editor code in C#
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.
2019-07-05 09:38:23 +02:00